[Sandy] Sandy 3.2, haxe / AS3 integration
damonsbane at gmail.com
Mon Mar 9 12:54:53 PST 2009
As I was pointing out to Neil on irc, I'm thinking that the 'small and fast'
approach to Sandy is in order, in more ways than one.
I am delighted that you are interested in the Haxe approach to head
development, as my one test so far (lightdemo) runs ~9,800ms in as3 and
~9000 ms in haxe... ok, so it's not the best test on the planet, but it does
show some significant difference.
The other part of 'small and fast' is assets. Yes, Collada's wonderful and
all... but have you seen the size of a collada file? Don't get me wrong, we
do need to improve it, but concentrating on binary formats will improve the
user experience. I'm working on the MD3 importer, since, afaik, it's a
little faster than trying to do IK for animations, again improving the user
As far as the renderer is concerned.. haxe has FastList, which would
certainly be a better choice for storing vertices/points/whatever if they
can be accessed in a serial fashion. The drawback here is the fact that the
whole engine would need to be rethought for lists instead of arrays. We can
also have immutable Geometry based on Lists, and mutable with arrays.
The haxe branch already has some flash 10 optmimizations. I've also already
started testing haxe's flash.Memory as well to see where it can improve
performance, but it's a tricky beast to balance indexing the memory region
vs. the read/write performance increase. Working with BitmapMaterial has
shown that the net effect was ->zero improvement<-, 300 lines of code later
:/. I _will_ eventually figure out where to use Memory, but in the mean
time, flash.Vectors and haxe.FastList should be kept in mind.
Getting Sandy running on Neko should be pushed to the forefront. It would be
so nice to have Sandy3d running in a console app with the same code base as
all, but it certainly won't have the same impact.
On Mon, Mar 9, 2009 at 1:15 PM, kiroukou <kiroukou at gmail.com> wrote:
> Hello Niel,
> happy you started that discussion.
> In my opinion, the future is on haXe platform. This is why I'm more than
> happy you joined us and started that project.
> Now the haXe version is stable and faster?(some benchmark could be useful),
> that haXe will export SWC very soon, I'm for making the haXe branch the main
> About the features, I'd see a better workflow with 3D tools. It means a
> better parser (especially the collada), and tools like basic collision
> handling etc.
> About the current haxe branch, indeed branching would be useful. As I
> expect the AS3 trunk to remain the last AS3 version, I'll not branch the AS3
> About 3.2, I see a flash player 10 features handling. Some parts of the
> renderer might be rethink, as the Material/Attributes stuff which can be
> simplified/unified (need to retrieve older disussions). I also like the way
> haxe3D handle the light, maybe Makc can check it, and see how this approach
> perform against our current one.
> Great ideas about the MD3 import ! We can expect some cools demos after
> that :)
> Thomas Pfeiffer
> kiroukou at gmail.com
> Le 9 mars 09 à 20:44, Niel Drummond a écrit :
> Would like to open the discussion on 3.2 and how to continue with haxe /
>> AS3 integration, also what features are desired by the developers.. Next
>> version could also be 3.1.xx
>> Russel is working on an MD3 importer, which also supports keyframed
>> animations - this means you can import QuakeIII models. Potentially a
>> wavefront importer is also in the pipeline. Obviously, any code going into
>> haxe branch should flow back into the AS3 port, I am ready to help here..
>> what do you think if we branch the 3.1 version in the haxe tree, and allow
>> the trunk version to get some updates beyond the AS3 version, which we can
>> then backport ?
>> Please 'spill the beans' on your idea of the future of sandy if there are
>> any plans we should take into account.
>> - Niel
>> Sandy mailing list
>> Sandy at osflash.org
> Sandy mailing list
> Sandy at osflash.org
More information about the Sandy