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!

[Widget]

Truly remarkable work, annikk... yet again 

Have you ever considered working on games or programs of your own?

[annikk.exe]

Thanks for the kind words.  :>

I've thought about it, but I'm pretty happy working on Eufloria.
I only wish that I could spend more time on it.  I am not exagerating at all when I say that right now, my dream lifestyle would be to work 80 hour weeks coding new mechanics and levels, writing programming guides and helping all you guys to learn new stuff about it.

Sadly, I need a plan to feed myself and my kitten as well.

[Bonobo]

 I think you are a saint, Annikk-Baba

<edit>

Again, not talking about your output but about your striving. Om shanti, shanti, shanti.

</edit>

[annikk.exe]

A saint? :P  Steady on!  You could just as easily call me a helpless addict.. :P

Speaking of which, I have made the following modifications to the 3D Starfield Engine, as it shall now be known:

• Fadeout thresholds are now assigned per-star.
• Added variable star size - now each star can have its own unique size.
• Removed all references to "layers".  With a full 3-axis coordinate system, parallax layers are an obsolete concept.
• Star colour is now set on a per-star basis.
• Stars now have a "drawn" size as well as a "given" size.  This is so that far away stars look smaller than nearby stars.
• Updated all the comments and line spacing to reflect the new methods added over the past few days.
• Spent a little time optimizing for performance.
• Decided that star chasers are really cool, and moved them to their own function ready to be transported elsewhere.

Now to copy and paste the engine into my new project.  :>

[annikk.exe]

This is an in-game screenshot.

[Aino]

This is awesome, tried the Parallax engine yesterday... I was simply amazed, you can fool any brain

[annikk.exe]

Those large stars in the foreground are in motion, by the way.  :>

[Bonobo]

Sitting here in awe …

[annikk.exe]

It now seems like this will not get released until this bug is fixed (which may take a while) or until I figure out how to convert between LevelDraw coords and Screendraw Coords (which may also take a while).

I would also be tempted to wait and see if Alex is up for implementing this feature which would dramatically improve the performance of the engine and allow it to be as spectacular as possible.

[annikk.exe]

Ok so.... I've realised that it's the game's normal scaling procedure fighting against my 3D engine.  When the camera is zoomed in or out, the game's native 2D scaling tries to move them to where they ought to be in a 2D scheme, but then the 3D engine gets the updated GetCameraScale, and moves them back again.  This is what causes the jitter which now foreshadows my days and haunts my nightmares.

I've tested the code in ScreenDraw as-is.  While the stars are all over the place, and move in bizarre and completely incorrect ways, the jitter bug is definitely not there.

So there it is.  The tantalising solution to all problems lies in rendering the stars inside ScreenDraw instead of LevelDraw.  It's going to be hella-difficult though.



Okok...  so the reason it looks all funky after simply being copied and pasted into ScreenDraw, is that LevelDraw (where is was before) considers all coordinates to be positions in the 2D plane of the level, whereas ScreenDraw considers them to be coordinates on the screen - literally on your monitor - I assume ranging from 0 to 1920 on the X axis in fullscreen if you're lucky enough to have HD.  The origin (ie coordinates 0,0) in ScreenDraw is considered to be at the top left of the screen.


So I figure, sure... I'll just subtract the Camera position from the Star position, and then if the star is onscreen, it would be displayed in a range that will show up in the ScreenDraw.  I tried that, and it fixes some aspects of the engine....the stars move correctly when panning around...  But for some reason, the scaling is way off.  When you zoom in, the stars get smaller and look further away.  When you zoom out, they seem to come closer and grow larger.  I've tried switching some random adds with subtracts, divides with multiplies, etc...  but stabbing around in the dark like that predictably did not produce results.

I've restored the engine to being rendered in LevelDraw for now while I think this thing over.  If anyone can offer any insight in this problem, I'd be grateful.  Hopefully my wall-of-text description will suffice...

[Bonobo]

I assume ranging from 0 to 1920 on the X axis in fullscreen if you're lucky enough to have HD.

I have nothing to say about all this b/c I’m a coding n00b. Or not even that.

But … how do you think this could affect screen rendering on a monitor w/ 2.560px*1.440px? Could it then be that playing this on my 27" iMac (Parallels Desktop etc.) could lead to rendering problems? Lags? What else (if at all)?

[annikk.exe]

I've no clue.  Obviously I would find a way to make it render nicely at all resolutions.  I should really experiment with ScreenDraw a bit to figure out what it's like, I suppose...

[annikk.exe]

Still not sure how to do this.  I made some diagrams and paper models to try to help myself understand it last night, but I'm still none the wiser.  It's depressing.  :|

Guess I should look at the rally point code..

[annikk.exe]

Pilchard, I looked at your rally point code.  It looks like you use a function called GetMouseScreenX() which I didn't know existed.  :>  But I didn't see anything that takes LevelDraw coordinates and converts them to ScreenDraw coordinates, or vice versa.  It seems like you select the destination asteroid simply by checking player-selected asteroids when the player clicks on them.



Ok seriously, there _MUST_ be a way to do this...  a convenient method to convert not just one set of coordinates, but ALL sets of coordinates, from screendraw to leveldraw, and vice versa.

The way I figure it, if I can simply transfer one type of coords to the other, the engine should work fine.

Penny for your thoughts guys..?

[annikk.exe]

Does anyone know if these types of coordinate systems have names?


Is this what I need?

I can imagine Screendraw's origin as the top left... an angle is calculated, a radius line drawn at that angle, and where it ends is the point in the coordinate system.  I've no clue if this is actually relevant to my problem though.

[annikk.exe]

How to convert between them? :>


Subtract CameraX from the leveldraw value, gives you the screendraw value?

But the problem is that screendraw starts in top left, whereas leveldraw stars in "the middle".  So a star that is at 0,0 in leveldraw would be in the middle of the screen.  Then, if the camera is at 0,0 too, that same star would be drawn in the top-left of the screen when drawn in ScreenDraw.  I'm trying to work out if that's a problem or not...

[Aino]

You want the 0,0 point on ScreenDraw() to be the same as it is on LevelDraw()?

EDIT: If so, there is GetScreenWidth() and GetScreenHeight() Just take them and minus half of them to themself like this:

Code: [Select]

width = GetScreenWidth() - (GetScreenWidth() / 2) and the same with height, did I help?

[annikk.exe]

Hmm, yea.. That could work..

You may indeed have helped :_>

[annikk.exe]

Code: [Select]


starX[i] = starX[i] - GetCameraX() + GetScreenWidth() - (GetScreenWidth() / 2)
starY[i] = starY[i] - GetCameraY() + GetScreenHeight() - (GetScreenHeight() / 2)



testing now...

[annikk.exe]

Well, it's all nicely centred in the screen now.  Still rather broken though, unfortunately:





Why is the behaviour of zooming in/out affected by changing this to ScreenDraw?

[annikk.exe]

OMG

Got it working!!


Still a star size bug, but the behaviour of stars is otherwise back to normal!  IN SCREEN DRAW!!!



seed YES

[annikk.exe]

The engine now behaves just as it did in LevelDraw, except that the jitter bug that has been driving me nuts is totally fixed.  :>


Now, to figure out how to make the stars render behind the asteroids.. :>

[Bonobo]

What you write about the star size bug reminds me of how seedlings’ appearance is changing when zooming out … if they were just minimized then I wouldn’t be able to see them at all. COuld there be a connection?

[annikk.exe]

I'm not sure Bonobo... I don't think so...  I'm still trying to wrap my head around it, even though it's fixed now.  :>



Have some more eye candy..

[annikk.exe]

So now the challenge is to figure out a (substantially) cheaper way of hiding stars behind asteroids.

What I really need, of course, is the ability to choose whether to draw them before or after the asteroids.  I presume whichever is drawn second is drawn on top of the other thing.
I need to be able to insert a true or false as one of the commands passed to DrawSprite to instruct it whether to draw the sprite before the asteroids/seedlings/etc, or after the asteroids.  That would give the greatest flexibility.

But it's not possible currently, so I need to think of another way.  Checking for overlap o each visible asteroid against each visible star is too expensive.  I need something incredibly simple and fast, that doesn't involve iterating over lots of entities.

[annikk.exe]

Currently the way I check for overlap is as follows:

Each game cycle, before entering the star render loop, I first calculate the number of visible asteroids on the screen.  This is stored in an array.

Then the star render loop begins.  The position of the star on the screen is calculated.  If the star is "behind" the asteroids on the Z axis (ie, starZ > 0), and if the CameraZ is less than the star's Z (ie the star is in front of the camera), then the star's rendered coordinates are checked against the positions of all asteroids in the array we just created.

This involves running a new for loop to check the star against each visible asteroid in the array we created earlier.

So if there are 400 stars and 2 asteroids onscreen, 800 iterations will be carried out.
If there are 400 stars and 40 asteroids onscreen, 16000 iterations will be carried out.
It's easy to see why this causes massive framerate drops... carrying out 16000 iterations 60 times per second is a bit insane really.

Because this part of the engine is so computationally expensive, I do some cheap checks first to try to "rule out" the possibility that the star could be overlapping with each asteroid.

First, I check if (StarX - AsteroidX) > AsteroidRadius.  If true, then there is no way they could possibly overlapping, and subsequent checks are unnecessary.  The vast majority of checks return true at this stage, rendering additional more expensive checks unnecessary.  However, some asteroids which are horizontally aligned will return true, in which case we proceed to the second "cheap" check.

The second check is exactly the same, except for the Y axis:  if (StarY - AsteroidY) > AsteroidRadius then the star cannot possibly be overlapping with this asteroid.  Having checked both of these, we can say that we've checked the "bounding box" of the asteroid.

If we have a bounding box overlap, then there's nothing for it but to do the expensive check where we see if the star _actually_ overlaps with this asteroid.  If it does, the star will NOT be drawn.


So that's how it works at the moment.  Any ideas for total optimisation ?

[annikk.exe]

Question for anyone who knows lots about programming.

Which is cheaper?


This:

Code: [Select]

for i = 0,50 do
for j = 0,500 do
variable1 = 1
end
end
or this:

Code: [Select]

for i = 0,500 do
for j = 0,50 do
variable1 = 1
end
end
?

[Sniped50]

Well, I'd imagine that if you had more commands within the first for loop and after the second for loop, then running through those 50 times would be cheaper than running through them 500 times. Beyond that... I don't know. They look like they'll take up exactly the same amount of memory.

My suggestion is... EXPERIMENT! I'm sure that is within your realm of thinking, is it not?

[annikk.exe]

Well sure, it would be normally... but making a massive structural change like that to the engine would not be trivial.  So I wondered if anyone knows if it's worth a try.

Currently, the engine looks more like the 2nd set of nested for loops (above), rather than the first.  Is it more efficient to make 50 large tables or 500 small tables?


Actually, I really doubt this would make an appreciable difference.  At the end of the day, it's still nesting a heap of loops..

[Widget]

I don't really know about programming but (given that the large tables aren't so large as to flood system resources) wouldn't fewer, larger tables be more efficient in the same way that performing an action on fewer, larger files is faster than performing the same action on more, smaller files in my OS?

I assume there's an associated overhead with referencing new tables as opposed to carrying out the same type and number checks against one large one.

Actually, I really doubt this would make an appreciable difference.  At the end of the day, it's still nesting a heap of loops..

On the flip-side, what you say is probably true. I would expect it to make a difference of some sort but what scale of difference is beyond me.

[Sniped50]

Is it possible to make an if check in LevelSetup()? And would drawing the stars before the asteroids would in fact mean the stars will always be hidden behind asteroids, no matter what happens before/after?

If so, I have an idea; a longshot, but an idea nonetheless.

If not, forget I ever got your hopes up...


Oh, and Widget, yes it's possible that fewer, larger tables could be more efficient; it's like saying one 10kb file is better than five 2kb files, because despite both sets of files containing the same amount of info, you aren't forced to flick between files searching for what you want. But in the end, it doesn't really help with something like this because it's still storing the same amount of information no matter which choice you pick.

[Pilchard123]

I don't know how reliable it is, but I have a speed-tester for my code snippets. I'll run it a few times and tell you the results. You want me to post the tester too? Perhaps you can use it, or help me improve it.

EDIT: It reports no apreciable difference when either i = 50, j = 500    or when i = 500, j = 50, both take approx 0.64 seconds, with no difference in the output time at 15 dp.

Tester attached, set up with i=5000,j=50000. I know it says WHILE tester, but I can't be bothered to change it. If you want a while loop rather than a for loop, then either work it out, or ask here, athough to be honest, if you're worried about codespeed, then you probably are good enough to cope on your own. No offence meant.

[annikk.exe]

Is it possible to make an if check in LevelSetup()? And would drawing the stars before the asteroids would in fact mean the stars will always be hidden behind asteroids, no matter what happens before/after?

Yeah you can use "if" in LevelSetup.  You can use it anywhere you like.. :>

I have no control over whether the stars or the asteroids are drawn first; that's the whole point.  It's not simply a case of which function appears in the level file first.  It would need to be changed by Alex or something.

I think it would make sense to make that change, personally.  Drawings of all kinds are less flexible if you can't choose whether they appear behind an asteroid or in front of it..

[Sniped50]

Well...

I've thought about and tweaked my idea: why don't you have a new function that you can call at the end of LevelDraw, once it has finished with what it was doing? That way, LevelSetup initiates the global variables first, then LevelDraw gets to work with the stars, then at the end of that, a third function, which could be called something like AsteroidDraw(), is initiliased containing all the asteroid variables, rather than have them in LevelSetup.

Then you'll be sure that the stars are drawn before the asteroids. Now, either it will work beautifully , it will destroy Eufloria , I'm rubbish at coding , or you've already tried that . Which would it be...?

[annikk.exe]

It doesn't matter where the asteroids are declared, it's the order in which asteroids and draws are rendered to the screen. Don't think it will work unfortunately.. But if you can find a way to draw ANY sprite such that it's rendered behind astroida, I'd be interested to know how you did it. :>

[annikk.exe]

Hey, I wonder if I can just draw an asteroid sprite on top of all the asteroids...

Hmm, it might hide the roots though...

[annikk.exe]

Ok, seems like drawings ALWAYS appear on top of each other, regardless of the order the commands appear in.  So that approach won't work.  :<