incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Zwaga <rol...@stackandheap.com>
Subject Re: [RT] Flex and alternative VM targets...
Date Wed, 09 May 2012 14:28:16 GMT
>
> I would love Flash (you can replace "Flash" with whatever bytecode is
> compiled by Flex) to alternatively use OpenGL / DirectX  on the desktop and
> something like WebGL in the browser as it's rendering engine - this would
> really raise the stakes and make it a compelling target for game developers
> though, for the time being, it seems like Adobe has already made 3D gaming
> it's current focus for the Flash Player.
>

Hey Michael,

I suggest you search the mailinglist archive a little, this topic has been
discussed at great length.
A lot of us agree that the only way for Flex to survive is to become a
cross-compilation platform,
the way that this will happen isn't sure yet. The MXMLC compiler has been
donated and could be
retrofitted with cross-compilation capabilities. Of course, there is also
the new Falcon compiler,
which Adobe promised will be donated as well.
Unfortunately, their prognosis will be that Falcon will be finished by the
end of the year, and how
long after that it'll take before Adobe's legal department has cleared each
line of code and Falcon
is REALLY part of Apache Flex is anybody's guess. It could be well into
2013 before we see it happens.
(or maybe we'll get lucky)
Anyways, before Flex is ready as an SDK to be properly cross compiled it
will need quite a few
very deep changes to the overall structure and design. So, until those
compilers become concretely
usable, we'll need every spare moment to refactor the SDK.
If you feel like joining us in this quest, then by all means help out ;)
There's been quite a few discussions
already about which changes should happen inside the SDK to allow it to be
'cross-compilable', if you
have any thoughts on that, start a thread about it and see what happens ;)

cheers,

Roland

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message