|
-
Yes we can
 Originally Posted by Squize
same with me, posted there, too.
I think everyone who is annoyed about the issue should write a bug report here:
http://www.adobe.com/cfusion/mmform/...?name=wishform
stating that the beta player achieved way better performance than the release player and ask what is up there.
If you have a blog a blog post there might help, too.
Originally Posted by Squize
Perhaps if more people ask there we may get an answer.
Hope the same.
Originally Posted by Squize
As adobe's customers we don't have a god given right to anything, but I think we're entitled to have an explanation somewhere about the difference in performance.
We've been encouraged to join in the beta programme. Part of the beta2 changes was a huge performance increase ( Which it was ). Why release ( well two ) a beta with what turned out to be an artificial performance increase ?
Squize.
yeah, totally agree on all. Of course we have no assured right to expect that a beta or final release of this or that of their apps/technologies has this or that functionality. On the other side hyping the performance of the beta player, getting it hyped for free by all early adopter longtime flash platform developers in beta phase and then releasing something which is massively worse in performance is borderline to fraud in my eyes if it was intentionally done.
If it wasn´t done intentionally done but as result of some technical last minute issue i hope they react on it (fix it) when realizing lots of people see such performance differences and it is an issue.
Originally Posted by Sietjp
Andre Michelle posted the first comment in the post on http://www.kaourantin.net/ about the new player stating there that his audio hack doesn´t work with the release player and is very glitchy with it.
Last edited by tomsamson; 12-07-2007 at 12:29 PM.
-
Senior Member
Yes I saw the comment. But I've just tested and it works perfectly for me (Win XP IE v7). Can anyone test the fl-909 on other confs ?
-
Yes we can
the issue with that one for me is that it works but runs worse than with the beta player, i´m running dual core on windows cp though. Vista itself is more ressource hungry and therefore content running on it should be more optimized to achieve the same performance as on xp.
As André said it doesn´t run well for him on Vista anymore and did before with the beta player.
-
Senior Member
Plausible answer (but im just guessing here): The beta had no frame or CPU consumption cap, (which is unrealistic for public consumer use).
-
Senior Member
Well this is avery bad news because I was working on the bitboy player ( http://board.flashkit.com/board/showthread.php?t=712120 ) and it uses the same sound hack...
-
Yes we can
yeah, i´m very disappointed, too, as i said i was working on stuff making use of that additional performance, too.
To Ray:
yeah,i´d guess so, too (if the performance drop is not just caused by some bug(s)) but then i don´t understand why that is done and also why the previous beta ran so nice and then the release player comes out with so much weaker performance (without several more beta versions in between to maybe adjust the performance or something else some more).
-
got some crashes with opera (not in firefox ) with some FLV loading stuff- hope they or opera will fix that at some point
-
Senior Member
Render, could u give links to site that crashes Opera with new FP? I would like to see if they crash my Opera too (PM the link if u dont wish to post it in public).
-
well not illegal (yet  )
http://songza.com/
(loads youtube movies and playbacks only the sound)
if I click on a song it crashes as soon as it starts to load- didn´t had that issue before because adobe recently forced me with the beta player because of some labs stuff I wanted to see.
-
Senior Member
hm, it does not crash my Opera. It doesnt work either since it stays on Loading and no sounds can be heard for any song but no crash.
-
Originally Posted by tomsamson
...this also goes way beyond showing "vector shapes" moving around at unbelievably high performance and it later turns out it was made using cacheAsBitmap which in real life scenarios is a feature one should avoid at any cost. ...
What do you not like about cacheAsBitmap? It makes using complex vector art possible for games. I've never had any problems with it.
-
hippie hater
CacheAsBitmap is waaay too slow compared to using BitmapData rendering with copyPixels, you can also use the vector art if you loop in each frame and draw() it to the array of bitmapData that the pixels will be copied from
Last edited by Cimmerian; 12-08-2007 at 05:37 PM.
-
Yes we can
to turtlesoup:
normally vector art is more performance intensive than using raster art as the shape/fill etc has to be calculated at runtime, each frame refresh.
Now the idea behind cacheAsBitmap is to store the vector art in ram like if it was a raster image once its look with its current props is calculated once (so it doesn´t have to be recalculated each frame refresh).
So far so good (in theory).
Downsides: the vector graphic still has to be recalculated any time you do more than just changing x/y pos of the graphic (for example changing rotation, scale etc). Then that caching has to be redone (which costs ressources each time, too)
which in effect means it runs with worse performance if you have cacheasBitmap turned on for a vector graphic and constantly change is scale,rotation etc.
Ok, then let´s just say we don´t change the scale,rotation etc of the vector graphic but really just the position (in which case one could think right from the start why use vector art if i don´t intend to change the scale, rotation etc at runtime anyway, but yeah..).
Is using cacheAsBitmap on the bitmap then a better choice than just having turned the graphic into a compressed raster image at creation time and having used it like that?
No, because cacheAsBitmap doesn´t store the image compressed as if you for example had that graphic imported as png 8 or jpg. Therefore you use up more ram at runtime.
In my eyes using cacheAsBitmap therefore only makes sense for code generated runtime only existing vector art (using the drawing api) which doesn´t change anymore during runtime (for example used in component graphics).
So yeah, all in all, there is a very specific isolated case where its a good choice but its not at all a feature one should constantly use for all creation time made vector art.
Last edited by tomsamson; 12-08-2007 at 06:04 PM.
-
Hey tomsamson & Cimerian,
thanks for the replies. My current game has avatars that move (and animate) around occasionally. When they move they do scale occasionally (in addition to the animation) but they are just standing around a lot too. Everything is vector art and I've been using cacheAsBitmap. Mainly for the standing around images but also for clothing they wear that doesn't scale.
I have thought about drawing the animations to bitmapData and then copying the bitmapData to the screen when the avatars move. Is there a way to save them as compressed images at runtime? It has to be at runtime because the avatars can swap clothes around in game. There would be way too many combinations to save off outside of runtime.
Sorry to derail the thread. But with regards to the new update, it fixed a crash bug I was having so I'm pretty happy with that. I haven't really noticed a change in performance but I never installed the beta update.
Last edited by turtlesoup; 12-08-2007 at 08:06 PM.
-
Yes we can
if you only use cacheAsBitmap for cases where the graphic doesn´t change in scale/appearance than you can do that (although, yeah, even then having a compressed raster image in first place is a better choice).
If you use cacheAsBitmap on graphics that change in scale a lot that is no good choice (also performancewise).
If you have a setup where you have many images in keyframes in a timeline maybe you should just convert the individual assets into compressed raster images.
Regarding runtime compressing bitmapdata: In theory you could work with bytearray and use some compression algo on that of course, but in reality if you have many art assets going that will probably end up beeing too ressource intensive for runtime game usage.
I´m glad the release player fixed a crash that annoyed you (though i´m not sure if the last beta player didn´t already have that improvement, too  )
and yeah, if you didn´t try the beta player with performance intensive stuff to compare (or haven´t tried it at all) then you can´t know what we moan about of course 
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|
Reply With Quote