The "I want to but I can't" modding requests thread

[Avaguard]

so can u at all  change hoe a seed looks i no that u cant but heck might as well ask

[annikk.exe]

Well, the appearance of seedlings is governed by the asteroid where they were "grown".  :>

So if an asteroid had lots of energy, the seedlings will be physically large, with large bodies.
An asteroid with high energy yields seedlings with long noses.  :>
Finally, seedlings with high speed have larger wings.


As for changing the properties of an existing seedling, that is something I've been meaning to figure out.  I think someone posted a way to access a matrix of seedlings...the rows were asteroids, and the columns were the seedlings present at that asteroid.  I'm not really sure though, it requires more investigating.  Feel free to dig in if it interests you!  They say you should learn to walk before you run, but that's a load of garbage.  You just need something to run toward.

[annikk.exe]

PS:  I haven't tested it, but I believe this command may add a ridiculous looking "pinocchio" seedling.  :>

Code: [Select]

GetAsteroid(0):AddSeedlings(1,1,1,100,1)

[annikk.exe]

Alex,

I really need to be able to choose whether stars are rendered in front of, or behind, asteroids.

At the moment the 3D Starfield engine involves large overheads checking whether any asteroids are in the way of any stars.  Consequently, when lots of asteroids are onscreen, the framerate of the game plummets.

I have gone to some pretty crazy lengths to optimise it, I'm using local variables wherever I can and I've even implemented cheap single-dimension and bounding box checks to try first.  I break my loops whenever possible.  After poring over it for hundreds of hours I am convinced there are no further inefficiences in the algorithm.  It's absolutely the most lean and efficient it can be....There's just... I can't really push it any further.


My tests show that if I don't bother hiding stars behind asteroids, the code runs MUCH faster.  It's because all the onscreen stars don't have to be checked against all the onscreen asteroids.  Indeed, it's no longer even necessary to make a list of visible asteroids...but the main difference I believe comes from getting rid of that huge nested loop.

So if it was possible for me to specify whether leveldraws appear in front or behind asteroids (ie, are the asteroids drawn first, or are the drawings?), I could instantly optimise the engine to have thousands of stars and run smoothly no matter how many asteroids there are in the level.  It would be utterly transformative for my engine.

I realise you are super busy and this can all totally wait.  However, this is something I really want.  So if you get round to doing more updates/bug fixes/whatever at some point, please consider doing this!

[Widget]

I think I'm speaking for many people when I say annikk's not the only one who really wants it. I certainly find his parallax stars magical and would love to see the limits of what can be done with them 

[Mihhaelo]

I doubt it's what you were wanting, but attached is a bit of script i just made up that should demontrate a method to make seedlings, flowers and mines look a little different. It should be random, so if you reload, they should look different each time, although they're isn't a huge amount of variety available. If you have any questions, you're free to ask, but i'm extremely forgetful, so I can't promise the reply will be fast.

I was actually going to make a tower-defense map and use this method to change how the seedlings look, so each wave of the enemy looked different. I managed to make a nice UI system as well, whereby you had an energy bar, you could create asteroids with energy, and also grow tree's wherever on the asteroid you wanted. Unfortunately ran into a few problems with the defense tree's recognising the enemy and all the work-arounds were less than pleasing (for myself), so i gave up.

[annikk.exe]

Alex,

I really need to be able to choose whether stars are rendered in front of, or behind, asteroids.

Further to this, I've spent some additional time thinking about exactly what sort of functionality would fulfill my goals for the Starfield engine, whilst also giving maximum flexibility and extensibility for future drawing designs by myself and other designers.

As the 3D Starfield Engine has support for stars that are rendered in front of the asteroids as well as behind, I would ideally need to be able to choose whether they are drawn in front or behind asteroids on a per-draw basis.  As opposed to making the entire LevelDraw function always in front or always behind.

Here is my idea.  Rather than changing the existing DrawSprite command and breaking all existing levels that use it, how about implementing  a brand new DrawSprite command entirely, perhaps like this:

Code: [Select]

DrawSpriteBehind(int id, x,y, r,g,b,a, size)
Please note that this would need to work in ScreenDraw as well as LevelDraw!  Parallax draws to LevelDraw, the 3D Starfield Engine draws to ScreenDraw (to avoid the native scaling when the camera scale changes).


The addition of this command would be transformative for both Parallax and the 3D Starfield.  It would allow a huge number of stars to be rendered (i estimate about 1000 onscreen at any given time) and the framerate would not slow down when a large number of asteroids are onscreen.
That would then mean you could zoom all the way out, and the stars would still be visible without significantly dropping the framerate.

This change would make the difference between "pretty" and "spectacular".  I realise you're busy with PSN stuff now, which I completely agree is more important than this request, and it may be months before you finally read this, but I'm just writing it all down now while it's fresh in my mind.  :>

[Aino]

I would like what annikk is desiring too, been thinking of a cool background feature

[Aino]

But when you make DrawBehindroids... you can simply add layers(it's maybe easier said than done though...).

Normally you have:

Code: [Select]

Drawsomething(id,x,y, r,g,b,alpha,size)or alike, but if you just add a layer number before the id(in some cases x) then layer 0 might be infront of roids, 1 behind and then 2 behind 1, etc...

Get it?

EDIT: Got big plans for this, making some fancy backgrounds...

[Mihhaelo]

Call me crazy, but couldn't you simply do a distance check on the asteroid, and simply fail to draw the sprite behind said asteroid? I'm not sure why alex would waste his time writing a function that you could simply implement yourself.

If it's too CPU hungry, you could simply make your own coroutine or have it on a timer.

[annikk.exe]

Mihhaelo, that is basically what the Starfield engine does at the moment.
It takes each star and compares it against each asteroid, until it has checked it against all the asteroids or it detects an overlap.
For overlap detection, first it checks for an X-coordinate overlap.  If there is no x-coord overlap, the star cannot possible be overlapping with the asteroid.  But if it finds one, it then checks for a Y-coordinate overlap, giving an effective bounding box check.  If the bounding box check indicates no overlap, the star cannot possibly be overlapping with the asteroid.  However, if there is a bounding box overlap, it does a full overlap check.  If overlap is then confirmed, the star is not rendered.  The one-dimensional checks are much cheaper than a real check, so we try to rule out the need for a real check in as many instances as possible... for efficiency reasons...

We HAVE implemented it ourselves, but doing it in Lua is not efficient enough.  Have you even seen the 3D Starfield engine? :>  I've spent hundreds of hours on this problem...

If it's too CPU hungry, you could simply make your own coroutine or have it on a timer.

If you have any information that could lead to further optimization of the 3D Starfield Engine, I'd be very interested to hear about that!  Please elaborate.

[Aino]

Yo annikk, where you been man?

[annikk.exe]

Hiding under a rock :>

[Aino]

Ok... Been very silent without you here it seems... Maybe someone talking once a while(except me, I talk alll the time xD)...

[Mihhaelo]

Well as I stated, you could create your own coroutine. You could then use os.clock to enforce a limit to how much cpu time a specific part of your code is using. Since you're using a coroutine, next time you call it, it'll pick up from where you left off.

http://lua-users.org/wiki/CoroutinesTutorial

There's a tutorial.

Also (and i realise this is a less elegant solution)... But if you coloured your asteroids in team colours with an alpha setting of "1", you don't even need any checking code