Problem with parallax engine

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