Hmm, I saw a fix for layers on Android but I don't think it's this one. I'll check.Quote:
Originally Posted by haoujey
Printable View
Hmm, I saw a fix for layers on Android but I don't think it's this one. I'll check.Quote:
Originally Posted by haoujey
Thanks for the new update! can't wait to try it out when it releases on steam
- I don't know if I reported this before, but just in case, there is a weird layer alpha coeff bug that happens only on D3D9/8 (doesn't happen on D3D11 though)
The bug is related to object's and layer's alpha coeff
Example:Attachment 30664
Excellent looking update, as usual! The new 'Load Animations' action sounds particularly interesting and useful.
If you don't mind Yves, I have some questions about it in regards to how it works with the maximum image limit per application that Fusion has. I remember you once mentioned that a Fusion application cannot have more than roughly 65500 unique images in it. How is this limit affected by the new 'Load Animations' action?
*If an application has already reached the maximum allowed images stored inside of it, can the Load Animations action allow it to load more images beyond the limit at runtime?
*After you load animations with the new action, do these newly loaded animation images count towards the max number of unique images per application during runtime?
*Can animation images be unloaded from the application after they have been loaded into the application with the new action, or are they permanently added to the application until the application is closed?
*Lastly, the update notes mention that the application that exports and loads the .ANM files must have matching application properties ("build type, premultiplied images option, image RAM optimization option, graphic mode, etc"). Are there any application properties that do not affect the .ANM file or is it all of them? For example, if the property 'Show Debugger' is enabled when the .ANM is exported, can the application properly load the .ANM file if the 'Show Debugger' property is subsequently disabled? Basically could we have an all-inclusive list of which properties need to be the same?
1. Yes with the new action you can have more than 65500 images (65500 max in main application and as many as you want in ANM files), as far as you don't load more than 65500 images at the same time in a frame.Quote:
Originally Posted by Tek
2. What is important is the number of images you use in a frame, this number can't be higher than 65500.
3. The new images are automatically unloaded when either you quit the frame, or you load another animation in the object.
4. The Show Debugger property doesn't affect the images. Build Type, Graphic Mode, Premultiplied Images (if D3D11), Optimized images in RAM (2.5+ DLC) are the ones to check, I added "etc" but I don't see any other one really. On the other platforms only Build Type and Graphic Mode are important (for when the action will be implemented on those platforms).
Thanks for the info, Yves. This sounds like it will be immensely helpful. It looks like this is really going to change the way I plan out the art/animation side of development going forwards. :)
Layer compositing is a bit weird in DX 9 mode due to the library we use iirc, I don't think we can easily fix this.Quote:
Originally Posted by Linky
Was the fix related to moving layer causing collision to be offset on Android? (basically the collision stays in place while the objects move with the layer, was only happening on Android)Quote:
Originally Posted by Yves
Cause I had to do a convoluted solution for a mobile game I've worked on, was hoping to not have to workaround this on my next projects...
Edit: Yes, seems like it was this specific bug, thank you a lot for fixing it! Amazing update! Loving seeing new features.
There's one odd thing tho, through my testing, on previous builds it would return the object position exactly were the touch was in any runtime other than Android, but with the fix, the object position is reported misaligned now instead of the collision.
That's not a serious problem, cause I could just calculate the position with the layer position - object position.
But just felt I should mention that although this is a lot better and shouldn't be a big problem, it's still different from other runtimes.
Here's a comparison between Windows and Android, so instead of the collision being misaligned now the position value is, but like I said above, this is far less of a problem compared to how it was before the fix since I can compensate the position value with the layer position. Compensating the collision with click/touch in other hand would be impossible. (without a convoluted workaround at least)
Attachment 30668 Attachment 30669
A small suggestion for the new "Load animations" feature tho.
I presume it will be able to load animations during runtime, I see that you can export it without 2.5+, but I can't find anything to import on non-plus, so I guess importing is a Plus feature, which I don't mind.
But would be pretty cool if people could export animations on Fusion 2.5 Free version, this would allow people making mods for games without the need to buy (or pirate) Fusion 2.5.
These users might not be game devs from start but might get more interested in making their own games, becoming possible buyers.
Oh yes it's a 2.5+ feature, the export option shouldn't be there if 2.5+ is not installed, must be a mistake.Quote:
Originally Posted by NaitorStudios
Well exporting if you can't load doesn't make lot of sense, and allowing it just for game mods is a bit weird... Plus anm files may be hidden if you put them in embedded binary files.