L B

I'm posting this in General Discussion as this has nothing to do with programming. My #1 scene, Three Bridge (the one in every Aerora screenshot), decided to stop rendering shadows from the directional light in 2.32. It renders them in-editor, but not in-application. This at first would seem I have done something wrong in my coding - however, another scene, loaded the same way, has shadows on its directional light. I made all the directional light settings the same across scenes. It shouldn't be in this either. Therefore: -Shouldn't be about the coding, Scene 2 displays fine with same code. -Shouldn't be about the light settings, Scene 2 displays fine with the same settings. -Shouldn't be about the dependencies, Scene 2 displays fine with the same files. Any idea? This is getting utterly annoying. using Leadwerks; public static class Base { private static void Main() { try { Engine.Initialize(); Framework.Initialize(); Filtering.Optimize(); FileSystem.Initialize(@"C:\Program Files\Aerora"); } catch (LeadwerksException e) { Debug.Alert(e); Engine.Terminate(); } Framework.Effects.VolumetricLighting.Enabled = true; Framework.Effects.Bloom.Enabled = true; Framework.Effects.DepthOfField.Far.Enabled = true; Framework.Effects.DepthOfField.Far.Range = new Range(50, 700); Scene.Load("abstract::Three Bridge.sbx"); while (!Window.HasRequestedClose) { /* Camera Code, not relevant {...} */ Timing.Update(); Framework.Update(); Framework.Render(); Graphics.Flip(); } Framework.Terminate(); Engine.Terminate(); } }

Basically, I made a map with 1m/t instead of 2m/t, which is my standard. I got somehow far in this map design, and at some point, realizing it was eating way too many FPS, I discovered (in wireframe mode) that I had doubled the resolution. My way of fixing it would be RAW > PNG, PNG /= 2, PNG > RAW, if that makes any sense. I'd like help on the RAW / IMG conversion.

Oh, saw pureLIGHT coming. Anyway, how can we use it? Don't see any baking option in the editor.

As title says.

Sad, we lost a user to an unreproduceable bug. Wait is that a word?

Considering you only apply this to a custom, sizable and placeable waterplane, I guess it wouldn't be too memory consuming?

Our wrapper is already OOP, you shouldn't touch a IntPtr at all. Example: Mesh cube = new Mesh.Cube(); cube.Position.X -= 3;

I have no idea. 10 might be a bit far for the cube. Try 5, especially if your window is small. Also, try World.Render(-1).

Could you post your complete code, without that copy/paste bug?

There is no camera. Try creating one with: Camera camera = new Camera(); By the way, some parts of your code are repeated.

Sad, another one gone to UDK. I wonder if HeroCloud will start dragging (more serious) users from LE, with its relatively low costs.

+1 on this. Never understood this marketing technique, but I'm sold anyway. As days pass, I'm becoming more and more sure that Lumooja is in fact a reincarnation of GLaDOS.

Unfortunately, there isn't.

I would add the following categories: Gets in the framework, extremely useful for option dialogs (effects, etc). Gets in the graphics, extremely useful for option dialogs (resizing, etc). I know it is possible for me to store whether effect X has been enabled, and keep that variable, but it is theoretically bad practice as such value could be changed without my application getting notified, leading to unexpected behavior. It is only expectable to have a get where you have a set, and vice versa. Framework GetStats GetZoom GetSaturation GetBrightness GetContrast GetAntialias GetSSAO GetGodRays GetHDR GetBloom GetWater GetWaterAmplitude GetReflectionElements GetWaterVisibility GetWaterSoftness GetWaterColor GetWaterHeight GetWaterWaveSpeed GetDistanceFog GetDistanceFogColor GetDistanceFogAngle GetDistanceForRange GetBackgroundMode GetBackgroundColor GetSkybox GetNearDOF GetNearDOFStrength GetNearDOFRange GetFarDOF GetFarDOFStrength GetFarDOFRange Graphics GetWireframe GetOcclusionCulling GetHertz GetFlags GetDepth

+∞ Is, Has, Can and May are verbs, not prepositions.

I call this torture.

Voldemort?

Tyler and I maintain them. They are up to date as Josh provides us with code and update news frequently. However, the updated, stable and usable version is not public yet - only Tyler and I have access to the SVN. (Note to the developers who have sent me private messages to get access to the SVN: Access will be given after the next major release. We believe it is importabt we lay our ground structure before letting people tinker with it. All who request it will get source access, and trusted developers will be allowed to commit officially. Again, we will distribute builds in binary (DLL) form on this forum, so you don't need to worry about compiling. ) It is a trustable choice to use C# for your game development, I would however strongly advise you wait for the next major release that will come with many great new features and improvements. On a last note: There are many forum topics about the headers, and I would glagly clean them up, however as these are not official (yet), no moderation by Josh can be done in these forums.

This GPU is not for me, but for a friend with low budget. Therefore, can I trust the "350W", or is it actually the "300W" reading I should trust? I personally have a 500W PSU.

The art of not answering a question.

Looking for a new GPU at the moment, which requires a 350W PSU. I have the following sticker, where I can see both 300W and 350W. Is this enough?

Mm, only things I want to take from that is a better tree wind animation and carved-in terrains built-in. (I know I can make my own models, but heh).

I think this calls for a bug report for EAXSupported not behaving as expected.

I guess EntityDistance does the Pythagorean algorithm anyway. And still, this allows for a low Y value and high X value or vice-versa. The best method for your situation would really be the physical sphere, or a center inequation from the conics formulas.

Only thing I can think of is Elfen Lied. But I doubt it.