[Papervision3D] OpenGL support in AS 3.0
Rob Bateman
rob.bateman at gmail.com
Tue Dec 4 18:44:08 PST 2007
>
> As i said i think hardware acceleration would bring all flash users
> performance improvement benefits, not just pro coders on creator side
> and high end computer owning users on audience side and i see it as
> problem that this is ignored and ONLY those other ways i listed before
> are applied.
point taken. I think we're due quite frankly. Even Tinc Uro admits that
there are elements of the flash 4 rasteriser still in the render code. It
could to with a kick up the arse.
Which way do you think is more approaching a mainstream audience? A way
> in which all gain propper performance without having to think too much
> about it or a way in which you ideally know how to deal with bitmapdata,
> have indepth oop coding skills and enjoy to fiddle with how the garbage
> collector works to gain some performance?
well i think that's the holy grail for any language. It remains to be seen
how Adobe manage with that one ;)
Rob
On Dec 5, 2007 1:04 AM, tomsamson <blumenzuechter at gmx.de> wrote:
> Sorry, but yes, i DO mind converting all my code to haxe or some other
> language.
>
>
> "Then don't. I was merely suggesting it as a way this is possible now.
> Haxe is actually very similar to as3 - it's based on the same ECMA
> standards and the differences are cosmetic at most."
>
> -->Yeah, np man, i don´t moan for you suggesting it, i moan for me
> having to think about using such things cause flash/the player isn´t up
> to it in other ways.
> If the day had 48 hours or i just had way less to do i´d love to play
> with haxe and tons of other things, but yeah, neither is the case so
> that i´d like to have the functionality in usual workflow with the flash
> related dev tools.
>
> As i said, i think the major problem with all those manners to get
> better performance in flash content
> is that its alienating a huge part (in my eyes the majority) of the
> flash platform content creator community.
>
>
> "fair enough. I would agree that if it's speed you're after with a game
> etc, rather than requesting a bunch of low level commands to be
> shoehorned into the next version of flash, just use something more
> powerful that's fit for purpose. "
>
> -->Yeah, you´re probably right.
> Maybe i just worked too long on all flash platform related stuff and am
> sad of giving up on it easily.
> While talking about it i´m not against getting more low level access to
> be able to get better performance or more functionality in general; i´m
> against having lower level work manners as only option for getting
> propper performance.
> Which leads us to the next point:
>
> "I'm not a machine code guru, but i suspect the reason why lower level
> commands are in faster languages is that they're necessary."
>
> -->Yeah, sure, again, not speaking about having lower level
> functionality as additional bonus; speaking for having more options.
>
>
> So yeah, because it doesn´t solve all issues but just some it shouldn´t
> be done?
>
>
> "umm, no. I was merely pointing out that you are not going to get stuff
> running as fast as desktop-based languages with a graphic upgrade, you
> would require a subsequent code upgrade too. Which is a lot for Adobe to
> concentrate on, especially when in a previous argument your saying that
> simply focussing on performace enhancing updates is alienating the flash
> platform community. "
>
> -->I´m not asking for performance comparable to C++ apps (would be nice
> but is just unrealistic with an interpreted language). I´m not asking
> for Adobe raising the code execution performance at the same time
> (within the same release) as boosting the display stuff handling
> performance. I´d be fine that since we got mostly code execution
> improvements with the previous release the focus would now be on display
> handling improvements with the next release ;-)
> I didn´t say
> "simply focussing on performace enhancing updates is alienating the
> flash platform community. "
> at all, that´s nonsense stated like that.
> I said that i feel like performance raising is heavily required,
> especially on display stuff handling side.
> I also wanted to express that where i see the problem is in which ways
> it is tried to gain performance and in which ones it is not tried. Most
> of the ways in which it is tried would be nice additional bonuses for
> pro coders (AS3, lower level creation manners etc) and users with newer
> systems (multi cores) .
> As i said i think hardware acceleration would bring all flash users
> performance improvement benefits, not just pro coders on creator side
> and high end computer owning users on audience side and i see it as
> problem that this is ignored and ONLY those other ways i listed before
> are applied.
> And yeah, if you don´t believe having to code in lower level coding
> manners to get better performance going alienates a big chunk of the
> flash community then check out how many people still use flash mx and
> how few in comparison as3 and how many long time flash platform content
> creators don´t want to make the switch to AS3 and moan about it.
> I think evolution is great but one should in between question oneself if
> the evolution is completely going into the right direction.
> Which way do you think is more approaching a mainstream audience? A way
> in which all gain propper performance without having to think too much
> about it or a way in which you ideally know how to deal with bitmapdata,
> have indepth oop coding skills and enjoy to fiddle with how the garbage
> collector works to gain some performance?
>
> Anyway, wanted to reply to you but now i´ll go check out the new pv3d
> release, on that point we´re all united with the same opinion i guess :-)
>
>
> --
> __________________________
> Ugur Ister aka Tomsamson
> Co-Founder, Lead, Stimunation
> http://www.stimunationgames.com/
>
> play some games:
> -PowPool, 3D Billiard with a twist:
> http://www.candystand.com/play.do?id=18201
> -KICKFLIP Skateboarding:
> www.candystand.com/play.do?id=18111
> -JayIsAdventure, an oldschool adventure
> game we made for a contest in 2 weeks:
> http://jayisgames.com/cgdc4_redirect.php?gameID=20
>
>
>
> Rob Bateman wrote:
> > Holy crap!
> >
> > ok, lets deal with this a step at a time....
> >
> > Sorry, but yes, i DO mind converting all my code to haxe or some
> > other
> > language.
> >
> >
> > Then don't. I was merely suggesting it as a way this is possible now.
> > Haxe is actually very similar to as3 - it's based on the same ECMA
> > standards and the differences are cosmetic at most.
> >
> > As i said, i think the major problem with all those manners to get
> > better performance in flash content
> > is that its alienating a huge part (in my eyes the majority) of the
> > flash platform content creator community.
> >
> >
> > fair enough. I would agree that if it's speed you're after with a game
> > etc, rather than requesting a bunch of low level commands to be
> > shoehorned into the next version of flash, just use something more
> > powerful that's fit for purpose.
> >
> > It needs to get better performancewise, especially a lot better on
> > display stuff handling side and yeah, it should keep its strengths
> > while
> > doing so, not achieve it by forcing the developer to do things in
> > lower
> > level creation manners for every performance improvement.
> > Otherwise its getting less and less a good choice compared to other
> > thing as time goes by.
> >
> >
> > I'm not a machine code guru, but i suspect the reason why lower level
> > commands are in faster languages is that they're necessary.
> >
> > So yeah, because it doesn´t solve all issues but just some it
> > shouldn´t
> > be done?
> >
> >
> > umm, no. I was merely pointing out that you are not going to get stuff
> > running as fast as desktop-based languages with a graphic upgrade, you
> > would require a subsequent code upgrade too. Which is a lot for Adobe
> > to concentrate on, especially when in a previous argument your saying
> > that simply focussing on performace enhancing updates is alienating
> > the flash platform community.
> >
> > Rob
> >
> >
> > On Dec 4, 2007 7:01 PM, tomsamson <blumenzuechter at gmx.de
> > <mailto:blumenzuechter at gmx.de>> wrote:
> >
> > "Opengl support is already possible with haxe and xinf (if you don't
> > mind converting all your code to haxe)"
> >
> > Sorry, but yes, i DO mind converting all my code to haxe or some
> > other
> > language.
> > If the bottom line comment to getting propper performance with flash
> > content is always to learn another language (version) and working in
> > lower and lower level manners then i wonder why one should choose
> the
> > flash platform in first place.
> > And i´m talking about the flash platform as whole there.
> > If you make a component based hippo hyped Ria, hooray, you can make
> > stuff in high level approach in bloated xml syntax or drag
> components
> > around.
> > For most other things, things where performance is vital, the
> solution
> > with every version is "wanna performance, gotta do it lower level
> way,
> > just also takes more time, no worries"
> > As i said, i think the major problem with all those manners to get
> > better performance in flash content
> >
> > (like having to deal with how the garbage collector works, strong
> data
> > typing, overall learning a more coder oriented lower level language
> > version, doing everything in code only centric manner, ideally
> > bitmapdata based instead of working visually in the flash ide, god
> > beware using movieclips etc)
> >
> > is that its alienating a huge part (in my eyes the majority) of the
> > flash platform content creator community.
> >
> > Next up, yeah, it may attract a good chunk of java or some other
> > language coders to be able to work in more similar ways on flash
> > content
> > like they are used to from their previous language.
> > But on the other side i think there´s also a big chance that many
> pro
> > coders working with flash start to think: hey, so i have to code in
> > manners as restrictive and time involving as in Java or C# etc but
> > still
> > the performance is so much worse than there (also the dev tools in
> > some
> > cases), what about switching over to that other thing then instead?
> > I know at least for offline content i´m already asking myself that
> > question more and more often with newer flash platform dev
> > tool/language
> > versions,
> > and more and more also for online content.
> > It needs to get better performancewise, especially a lot better on
> > display stuff handling side and yeah, it should keep its strengths
> > while
> > doing so, not achieve it by forcing the developer to do things in
> > lower
> > level creation manners for every performance improvement.
> > Otherwise its getting less and less a good choice compared to other
> > thing as time goes by.
> >
> > "
> > As to my opinion on an opengl'ed flashplayer in the future - i
> > think it
> > is not the silver bullet some people try to make out. Sure the
> > graphical
> > rendering would be much faster, but another bottleneck would crop
> up.
> > Most likely the as3 avm, which is a snail compared to the c++ based
> > opengl library. So speed issues would simply swing back to a coding
> > problem.
> >
> > "
> >
> > So yeah, because it doesn´t solve all issues but just some it
> > shouldn´t
> > be done?
> > If it makes the code execution performance be the bottleneck end
> > again
> > i´d be fine with that as i´d see it as great improvement if the
> flash
> > player could handle the graphical side for all things smoothly
> > which i
> > can do with it nicely running on codeside; would be a great
> > advancment
> > compared to the current state.
> >
> > I´d love to love the way the evolution of the flash platform goes
> but
> > yeah, i think a lot of strengths are lost to gain some others.
> >
> >
> > --
> > __________________________
> > Ugur Ister aka Tomsamson
> > Co-Founder, Lead, Stimunation
> > http://www.stimunationgames.com/
> >
> > play some games:
> > -PowPool, 3D Billiard with a twist:
> > http://www.candystand.com/play.do?id=18201
> > -KICKFLIP <http://www.candystand.com/play.do?id=18201-KICKFLIP>
> > Skateboarding:
> > www.candystand.com/play.do?id=18111
> > -JayIsAdventure
> > <http://www.candystand.com/play.do?id=18111-JayIsAdventure>, an
> > oldschool adventure
> > game we made for a contest in 2 weeks:
> > http://jayisgames.com/cgdc4_redirect.php?gameID=20
> > <http://jayisgames.com/cgdc4_redirect.php?gameID=20>
> >
> >
> >
> >
> > Rob Bateman wrote:
> > > Opengl support is already possible with haxe and xinf (if you
> don't
> > > mind converting all your code to haxe)
> > >
> > > http://xinf.org/trac
> > >
> > > http://haxe.org/ <http://haxe.org/>
> > >
> > > haxe is basically a slightly different flavour of as3, and xinf
> > is a
> > > library that can be used to access opengl commands through neko
> (one
> > > of the runtimes that haxe can compile to)
> > >
> > > Now. Someone has already tried converting papervision to haxe
> here:
> > >
> > > http://hi.baidu.com/actionscript3/blog/category/Haxe
> > >
> > > but i'm not entirely sure of the details as the site is in
> > Japanese.
> > >
> > >
> > > As to my opinion on an opengl'ed flashplayer in the future - i
> think
> > > it is not the silver bullet some people try to make out. Sure the
> > > graphical rendering would be much faster, but another bottleneck
> > would
> > > crop up. Most likely the as3 avm, which is a snail compared to
> > the c++
> > > based opengl library. So speed issues would simply swing back to a
> > > coding problem.
> > >
> > >
> > > if people really can't wait for opengl in the browser, then
> > maybe try
> > > the new opengl-es plugin here
> > >
> > > http://blog.vlad1.com/2007/11/26/canvas-3d-gl-power-web-style/
> > > < http://blog.vlad1.com/2007/11/26/canvas-3d-gl-power-web-style/>
> > >
> > > which utilises a new plugin available currently for firefox 3
> beta.
> > > plans for opera, safari and ultimately iexplorer plugins are
> abound,
> > > but at present unconfirmed.
> > >
> > > Rob
> > >
> > >
> > >
> > >
> > > On Dec 3, 2007 10:36 PM, Jon Bradley < jbradley at postcentral.com
> > <mailto:jbradley at postcentral.com>
> > > <mailto:jbradley at postcentral.com
> > <mailto:jbradley at postcentral.com>>> wrote:
> > >
> > >
> > > On Dec 3, 2007, at 2:07 PM, tomsamson wrote:
> > >
> > > > Personally i think graphic card support is more than
> > overdue for
> > > flash
> > > > now, as it shows most other attempts to gain performance are
> > > more and
> > > > more alienating the non pro coder sections of the flash
> > content
> > > > creator
> > > > community.
> > >
> > >
> > > It's not just graphic card support, it's OpenGL support. Not
> all
> > > graphic cards support OpenGL, and OpenGL implementation is
> > not the
> > > same across Mac/PC platforms.
> > >
> > > On the PC tip, Microsoft over the years has been piss poor in
> > > releasing libraries so that card developers can include
> > proper GL
> > > support on the cards (look at Windows Vista for a prime
> > example of
> > > poor OpenGL support - more than half the time it's not
> > available).
> > > Microsoft pushes DirectX, not OpenGL.
> > >
> > > Secondly, you run into major compositing issues. OpenGL
> > doesn't do
> > > vectors natively, it renders polylines. It's not going to
> > have the
> > > display quality of Flash. And, to mix the two environments
> > is asking
> > > for serious problems - a resolution independent display
> > medium with a
> > > bitmap medium.
> > >
> > > While I absolutely agree that some type of hardware support
> > would be
> > > awesome in Flash, it would be a major undertaking that I can
> > > guarantee would be fraught with bugs and lead to significant
> > > instability in the Flash Player across platforms.
> > >
> > > cheers,
> > >
> > > jon
> > >
> > > _______________________________________________
> > > Papervision3D mailing list
> > > Papervision3D at osflash.org <mailto:Papervision3D at osflash.org>
> > <mailto:Papervision3D at osflash.org <mailto:Papervision3D at osflash.org
> >>
> > > http://osflash.org/mailman/listinfo/papervision3d_osflash.org
> > >
> > >
> > >
> > >
> > > --
> > > Rob Bateman
> > > Flash Development & Consultancy
> > >
> > > rob.bateman at gmail.com <mailto:rob.bateman at gmail.com>
> > <mailto:rob.bateman at gmail.com <mailto:rob.bateman at gmail.com>>
> > > www.infiniteturtles.co.uk <http://www.infiniteturtles.co.uk> <
> > http://www.infiniteturtles.co.uk>
> > > www.away3d.com <http://www.away3d.com> <http://www.away3d.com>
> > >
> >
> ------------------------------------------------------------------------
> >
> > >
> > > _______________________________________________
> > > Papervision3D mailing list
> > > Papervision3D at osflash.org <mailto:Papervision3D at osflash.org>
> > > http://osflash.org/mailman/listinfo/papervision3d_osflash.org
> > >
> >
> >
> >
> > _______________________________________________
> > Papervision3D mailing list
> > Papervision3D at osflash.org <mailto:Papervision3D at osflash.org>
> > http://osflash.org/mailman/listinfo/papervision3d_osflash.org
> > <http://osflash.org/mailman/listinfo/papervision3d_osflash.org>
> >
> >
> >
> >
> > --
> > Rob Bateman
> > Flash Development & Consultancy
> >
> > rob.bateman at gmail.com <mailto:rob.bateman at gmail.com>
> > www.infiniteturtles.co.uk <http://www.infiniteturtles.co.uk>
> > www.away3d.com <http://www.away3d.com>
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Papervision3D mailing list
> > Papervision3D at osflash.org
> > http://osflash.org/mailman/listinfo/papervision3d_osflash.org
> >
>
>
>
> _______________________________________________
> Papervision3D mailing list
> Papervision3D at osflash.org
> http://osflash.org/mailman/listinfo/papervision3d_osflash.org
>
--
Rob Bateman
Flash Development & Consultancy
rob.bateman at gmail.com
www.infiniteturtles.co.uk
www.away3d.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/papervision3d_osflash.org/attachments/20071205/8894fc04/attachment-0001.html
More information about the Papervision3D
mailing list