Support for Legacy's "mist" trick

[StrikerMan780]

Couldn't the water effect like that be done via Shaders?

[Sussudio]

On a related note: I had a look at the setcorona code. Again the same style: All over the place, no thought put into it, ugly as hell and totally unusable. For example, the y-offset they set for their lights seems to come out of nowhere. I have no idea what they used as the origin. Maybe the center of the sprite graphic but I'm not really sure as that code makes my head hurt, bad as it is.

Sometimes I wonder how that engine could even work to the degree it did - which wasn't very high...

From an old interview: "If you had to get rid of all the new Legacy features except one, which one would you keep?"

"The one users and map authors like the most. But I want to keep dynamic/static lighting as well because that's the first new features I added to Legacy (with coronas), a few weeks after I joined the team. I had no idea on how to do that when I started coding it, but it went well quite quickly (probably thanks to my math teachers )."

That would explain a few things

Anyways, the mist effect is still killer and I have yet to come across coronae better looking than Legacy's. It had to be said, at least once.

[Sussudio]

Here's something more on the corona problem.

Legacy's coronae are objects, so let's picture them as sprites attached to other sprites (they cannot be "attached" to textures without trickery) Problem is, neither the corona lump nor fragglescript can be used to assign a corona to a random sprite because this information is hardcoded, that means, the developer picked up only the sprites he thought should have coronae, put coronae on them and made it so that no other sprite could have coronae, but gave you the tools to modify the intensity, transparency, color, radius, and more importantly, the offset of the coronae attached to the chosen sprites, so the offset you start with in fragglescript is presumably what proved visually acceptable for the developer, there's no "center of the sprite" or extra calculations, it's all manually predefined to suit the dimensions of each of said sprites so whatever value you input will be relative to that.

Here's what happens when you replace a sprite without modifying the default offsets:



Something tells me there's a chance you could be barking at the wrong piece of code (setcorona), but if not and you're indeed clueless about the aforementioned predefined offsets, then I guess this is hopeless.

[Firebrand]

From that screenshot it could be set from the objects height.

[Gez]

The Legacy code is full of hilarious comments:

Code: Select all

       // Bp; je comprend pas, ou est la rotation haut/bas ?
        //     tu ajoute un offset a y mais si la tu la reguarde de haut 
        //     sa devrais pas marcher ... comprend pas :(
        //     (...) bon je croit que j'ai comprit il est tout pourit le code ?
        //           car comme l'offset est minime sa ce voit pas !

For those who don't read French, this translates to:

Code: Select all

       // Bp; I dont understand, were is the up/down rotation
        //     you add an offset too y but if their you louk at it from above
        //     hit shoold not work... dont understand :(
        //     (...) okay I thinks that I've understanding this code its all roten?
        //           because as the offset is minimum hit dosent show!

(I've tried my best to render faithfully the horrible grammar and spelling with equivalent mistakes. :p)