With the latest release the engine has reached an state where I am quite happy with how things work and its internal structure. I know there’s tons of things that could be added and still there’s those ugly seams between planes and collision issues, but overall I think it is already a very usable piece of software.

One of the last things to really annoy me is how the engine freezes when rendering big scenes for the first time. As an example, enter the graveyard in the demo. This happens because the engine creates all the assets and graphics when you enter the scene, and it also renders all lights and shadows. This is annoying in small scenes ( it breaks the sense of flow an smoothness in a user’s experience ) and in complex scenes it takes simply too much time. Also this freeze is not a constant but it increases with the scene’s complexity and size, ultimately becoming unbearable for very large areas.

Lately I’ve been working on some optimizations that have turned out very well: now the engine only creates the assets for an element when the element scrolls into view. This means that the initial rendering for an scene only draws what is visible, and thus takes only a fraction of time (and RAM).

Which is how any render decent engine is supposed to work anyway: only draw stuff that happens within the viewport.

On top of that, the render engine now features a render message system. When the engine receives a render message for an element (calculate and draw a shadow, for example) if the element is outside the viewport the message is not applied but queued into the element’s render queue. When the element enters the viewport, all pending render messages are applied to ensure the element is shown with its latest status.

Furthermore, some messages invalidate older messages in the queue: imagine a light has been moving around: only the last movement message is to be applied when the element is shown. Ultimately, hiding the light will invalidate all previous light messages, as when the element is drawn there won’t be a light anyway.

Another benefit of this technique is that moving elements outside the viewport don’t stress the flash render engine.

Now I hear you saying: “this is something quite obvious to do and it should have been implemented this way since the beggining”. I know, but honestly when I first started the engine I didn’t imagine there would be a day when I would be dealing with scenes so big.

The only (tiny) drawback of this technique is that you may experience microfreezes when a big piece of ground or wall enters the viewport. I suggest having ground tiles no bigger than 500×500 to make sure this doesn’t happen, but it will depend on your application’s overall performance and the complexity of your materials. By the way the perlin material is now about 5x faster. Also an new fRenderableElement.ASSETS_CREATED event is added to know when the assets have been crrated and the flashClip property is available.

I have update MyNameIsPoncho ( see how nicely the demo swicthes scenes !! ) and the code repository. Let me know if you hit any bugs with it.