Krypton 2.0 changes

Feb 14, 2011 at 10:38 AM
Edited Feb 14, 2011 at 2:00 PM

Congrats on the latest release :D Video looks great. I'm having some issues upgrading:

 

Hull.Color: Uh oh. I was totally relying on that, it looked brilliant in my project. Is it gone forever? 

I wasn't using the colour aspect, just the Alpha, to soften shadows.

??

 

krypton.AmbientColor doesn't seem to be working - even at 255,255,255 the level's in pitch blackness unless illuminated by a Light2D. Has something changed that I'm not seeing, or is this busted?

 

krypton.CullMode ooooh what's this and do I need to worry about it?

Feb 14, 2011 at 2:09 PM

I've just seen this re ShadowHulls: http://krypton.codeplex.com/workitem/1

There's a beer in it for you if it can be the next thing on your list ;)

Coordinator
Feb 14, 2011 at 8:36 PM

It already is. I'm hoping for a weekend release. However, I removed it from this release for stability purposes, and because the new speedy rendering method didn't support it. (it will later).

Soon!

Feb 14, 2011 at 8:39 PM

Magic, thank you :D

What about the other two things? Any insight into what's going on there?

Coordinator
Feb 14, 2011 at 9:39 PM

danget. Ambient Color is probably not working -.- I totally took that out for some debugging stuff, and forgot to test it.

I'll fix it this evening. If you need it fixed now, go to KryptonEngine.cs, and update the line where Krypton clear's the light map color (in LightMapPrepare) and change it from Color.Black to this.AmbientColor

my bad.

Coordinator
Feb 14, 2011 at 9:41 PM

CullMode only needs to be changed if you're using a matrix that will invert horizontally or vertically (aka: spritebatch). So, if suddenly nothing is drawing when you change the matrix, try changing changing the cull mode. It's a works or doesn't kind of thing.

Feb 15, 2011 at 8:29 AM

Latest source code work a charm, thanks for that :D

Coordinator
Feb 18, 2011 at 11:54 PM
Edited Feb 18, 2011 at 11:55 PM

Thank you!

By the way, Shadow hull opacity is back in the newest changest.

Feb 19, 2011 at 10:13 AM

I have seen, it works perfectly. Thanks again :D

Feb 19, 2011 at 11:20 AM

So is culling working automatically now? I haven't really had time to look into what's happening in 2.0 - in passing my camera matrix to the engine, is it culling anything outside the viewport? Where's that code? I'd like to have a rummage...

:)

Coordinator
Feb 19, 2011 at 4:22 PM

I'm not sure exactly what you mean by culling working automatically. You'll still need to change the cull mode if you're flipping the x/y axis of the matrix. Krypton figures out the view bounds when you set the Matrix (see Krypton.Matrix_set()). Lights are then culled if they do not reside within the bounds of the view (see Krypton.LightMapPrepare()), in the foreach loop). Hulls are then culled based on their range from each light, regardless of the view bounds, as it's possible to have a shadow drawn from a hull which is not within the view bounds end up within the view bounds (see Light2D.Draw()).

What did you mean when asking if culling works automatically?

Feb 19, 2011 at 5:09 PM

// Lights are then culled if they do not reside within the bounds of the view

I think that's all I need to know. What I'm asking is, if I have a level with four dozen lights in it, Krypton automatically works out which ones aren't impacting anything on-screen and ignores them on my behalf?

Coordinator
Feb 19, 2011 at 10:39 PM
Edited Feb 19, 2011 at 10:39 PM

That is correct.

Keep in mind that the lights and view are "hit-tested" using AABBs, and thus if the bottom right hand corner of a light's bounding box is touching the view's bounding box, the light will still be rendered, even though the actual light texture may not end up effecting the final light map.

Also keep in mind that the more pixels drawn to the screen by the light, the longer the render will take. Thus, smaller lights draw faster than larger lights.

One more thing... The lights are not organized in quad trees, and neither are the hulls, so each light will be AABB-tested against each hull. Thus, the number of AABB tests is numLights * numHulls.

Coordinator
Feb 20, 2011 at 2:14 AM

I just noticed a bug, where the bounding rectangle will always be infinite, and never be useful. I'll get this fixed as soon as possible, and the above will work accord to how I've described. :/