Printable View
To put it quickly:
I have 5 background gradients, no events, in a app.
In Direct3D 8 it uses 60% CPU.
In Direct3D 9 it uses 50% CPU.
Other display modes use 0% (except at the very start).
Screenshot:
Bug!
Is this bug fixable or should I remove the Background Gradients from the app? :eek:
In Direct3d mode background objects are always displayed, so it's normal if it uses more CPU. It should not use a lot of CPU though, except if you use Ellipse shapes (ellipse shapes are not optimized for HWA, remove them from your app in this case).
Just normal gradient rectangle.
To clarify, it's not the backdrop objects, it's the Background Gradient Object. I consider a +15-50% CPU a huge (and buggy) jump. It suggests all the gradients are being redrawn with each frame rather than on frame 1 and when an action occurs.
The Background Gradient object (By Alien) is not HWA optimized. It will probably delete and create new memory all the time because it was designed around the idea that it would be redrawn very rarely. With HWA it is redrawn every single frame which kills the performance.
ah, I assumed it was HWA-optimised - when is Background Gradient object going to be HWA-optimised then?
Alien isn't around in the click community any longer. I don't know if he gave the source-code of his extension to anyone before he left. If he didn't then the chances of getting a HWA optimized version of it is very small.
So, if there's a chance it'll never be HWA optimized, please don't kill me for suggesting a workaround.
What I usually do when I need a custom HWA gradient is that I create an relatively small active object that contains the gradient I want, and resize it to the desired size using "set x scale" and "set y scale". It should only contain one single colour (so the gradient will be done with the alpha channel) Then I use the "replace color" action on the object, as well as on a solid coloured object behind.
I know it's a pain, but I just had to go through the same thing, but with the character image map which isn't HWA optimized either.
Someone with time on their hands (not me) could maybe write a HWA implementation of the extension from scratch.
If there was a HWA SDK, maybe :)
I agree, we really need HWA SDK
+1 vote for a SDK
+1 too, we really need a SDK for MMF2 Hwa.
Why?
Because! MMF2 HWA support a few extensions than MMF2 normal mode.
And, assuming this, the majority of our apps cannot be ported to MMF2 HWA because this annoying thing.
And, with MMF2 HWA, in FullScreen, some transitions work better !
Then WE REALLY NEED A SDK FOR MMF2 HWA Clickteam !
There's an SDK but third-party developers aren't allowed access to it :(
It would certainly make sense now that the HWA is meant to be finalised.
What's the point of having extensions if you can't make use of all of MMF2's current features?
Yeah i agree, HWA could be far more powerful also and a SDK would allow developers to take advantage of it's features.Quote:
Originally Posted by Crash86
I can imagine things like a Xlua style object to code the HLSL effects or working with them in surface object etc. Then there is the fact developers could fix objects that don't currently work correctly also which is another major reason for a SDK.
I have suggested clickteam release one quite a few times now. There is also another discussion about this here -
http://www.clickteam.com/epicenter/ubbthreads.php?ubb=showflat&Number=208791
That's wrong, there is no HWA SDK, I had no time to do it. I give info to developers who ask me, feel free to ask me if you want some info.Quote:
There's an SDK but third-party developers aren't allowed access to it
I'll try to collect the info I've given to Andos, etc and I'll write some documentation, but I've too many things to do at the same time at the moment.
You're kidding? 95% of the extensions work with MMF2 HWA. Also the limitation of the Windows controls in full screen mode discussed in another thread cannot be solved with a SDK, you have to create graphical objects for that (and those graphical objects can be done with the current SDK).Quote:
the majority of our apps cannot be ported to MMF2 HWA because this annoying thing.
No Yves, for a lot of GRAPHICAL extensions i did mean.
(and, also some of graphical extensions working with HWA do not support all Pixels Shaders DX9 mode)..
Then no, i'm no kidding, i'm thinking just it will be amazing, what i said.. FANTASTIC if Clickteam can release a DOCUMENTATION of HWA structure, seriously !
And.. Wait.. You've just said it will be the case, so, YES, Thanks Yves!
When you have the time some HWA documentation will be very useful, maybe you could add this info to the wiki or make a sticky post in the Extension Development forum.
Thanks Yves :)