Problem with parallax engine

[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.