Jump to content

loodakrawa

Members
  • Posts

    161
  • Joined

  • Last visited

  • Days Won

    19

Everything posted by loodakrawa

  1. Hey, at the moment this is not supported out of the box. I think you might be able to emulate this behaviour with Spriter's sub-entities. In the future, I plan to add a bunch of more advanced features but I'm quite time constrained so I'm not sure when that's going to happen.
  2. I assume it's just Unity being dumb as it occasionally happens. I recommend just deleting the currently imported animation and re-importing it again. If it still happens, I'll need more info - like what's null and what happened during the import of that particular thing. Hope this helps
  3. PCLs are a pain Yes, I recommend .NET Standard because everything is moving in that direction, especially with .NET Standard 2.0 coming out soon. More and more libraries are getting converted to .NET Standard and even Unity3D promised to add support for it which tells you something (since they've been stuck on .NET 3.5 since forever). Also, from my experience, .NET Standard libraries have no major issues accepting PCL NuGet dependencies in contrast to the other way around. Keep in mind that you'll probably need to add "Microsoft.NETCore.Portable.Compatibility" as a dependency if you're adding PCLs to a .NET standard, at least I had to do it do add MonoGame Portable as a dependency.
  4. I've investigated and this issue is happening due to the fact the animations don't have an identical layout (which is a requirement for animation blending to look right). For example, this is causing the head from animation 1 to be blended with something else (like an arm) from animation 2 which obviously results in weird things happening.
  5. Yes you are That method was added after that release. However, I just did the 1.6.1 release yesterday which includes that method. FYI, for this release I moved everything to .NET Standard libraries and did proper packaging. https://www.nuget.org/packages/SpriterDotNet/ https://www.nuget.org/packages/SpriterDotNet.MonoGame/ I also added the content importer as a package. Hopefully that helps with the Content Pipeline weirdness. https://www.nuget.org/packages/SpriterDotNet.MonoGame.Importer/ Please let me know if there are any issues with these packages. Cheers
  6. Hi, If there are glitches or issues with transforms I'll definitely investigate since the core problem might be a bug in the core library. There's a big difference between "It doesn't work" and "there are glitches" Can you please post as much info as possible about the issue so I can look into it?
  7. It was bound to happen. I put the development of the Unity version on hold at least until they decide to support a more modern .NET version. I think this means waiting for .NET Standard 2.0 since they said they will support it once it comes out. Unity 2017.1.0 seems to be on the right track with the (experimental) support for C# 6 and .NET 4.6.
  8. Hi, I'll do the MonoGame version soon (next couple of days) - I converted things to .NET Standard so I'm figuring out how best to package everything. As for Unity, I put it on hold until .NET Stadard 2.0 comes out and Unity starts supporting it.
  9. Hi Alex, I'm glad to hear you're using MonoGame You can get the point position with this helper method. And this is an example how it's being used - it's just rendering it but it should point you in the right direction. Let me know if you have any issues.
  10. Hi. This seems like a division by zero issue. Check the PPU on your SpriterDotNetBehaviour and on your Sprites - it shouldn't be 0
  11. My Geometry-Fu was strong today so I've pretty much done it. It's in a branch for now but I'm pretty positive I'll merge id in the main branch soon. I assume you want something like this. I had to come up with a new data structure since the MonoGame Rectangle is axis-aligned but hopefully this should be fine to use.
  12. Hi, ATM it's not really trivial to get that information out with the current version. This is something that has been requested a couple of times but I've been unable to find the time to implement. However, I have some time these days so I opened a ticket about this which I hope to implement in the next couple of days. Stay tuned!
  13. Ah, that makes more sense It depends on your architecture but I'd say you should do that when you load the sprites. In the example, all the sprites are loaded using an instance of SpriterContentLoader which gives you a lot of caching and sensible defaults out of the box. However, in a real game you probably want custom loading, especially if you want to control individual sprites. If you want to use that and just get a sprite, you can get it from the IAssetProvider's Get method with the given folder and file id. Hope this helps
  14. Well, that method is for swapping individual sprites with the ones you want - so it's up to the caller to have the desired sprites.
  15. Hi, I'm glad u use this as part of something custom built Anyway, for the things you want to do - there is a couple of ways of doing this. Make a sprite invisible: there's a Swap method which you can use to swap the sprite for a transparent one. you can implement your custom IFrameDataProvider and keep the transparency info in it and apply it on the appropriate SpriteObjects (the objects have the animation, entity, folder and file id so you can use that to identify them) you can implement yout custom Animator and kee the transparency info in it and apply it in the ApplyPointTransform method To make it point to a certain location: have a 360 rotation for the whole thing image and don't call Step on it but just set the Progress on the Animator to get to the exact point in the animation (== rotation) you want pause the animation and just rotate the whole thing if you need the whole thing animated with just one sprite pointed to the player - do something similar to what I described for swapping - keep the overriden position data in you own IFrameDataProvider or Animator Let me know if I missed something. Also, please let me know how you go with this and how did you end up fixing it because that might be something good to add to the library. Also, what do you use for rendering? Cheers
  16. Hey guys, To change sprites during runtime, either use Character Maps or swap sprites directly (for a more granular control). Both functionalities are achieved via the various IAssetProvider's methods (PushCharMap and PopCharMap for char maps and Swap and Unswap for individual sprites). Take a look at the Controller in the example project to see how it's done.
  17. Hi, The plugin looks very nice - good work! At the moment I'm really busy so I don't have the time to update SpriterDotNet for Unity. But if you've done it already, please submit a pull request - I'll be more than happy to merge it. (https://github.com/loodakrawa/SpriterDotNet/blob/develop/CONTRIBUTING.md) Cheers
  18. Sorry, thought I answered you - and today I realised I didn't. It's a bit hard to figure out what the problem is with just a chunk of code, but my guess is: animator = FindObjectOfType<SpriterDotNetBehaviour>().Animator; This finds a SpriterDotNetBehaviour - or to be exact, the first loaded one which is probably not the one you want. I can't really say from your code but I assume the animator is supposed to be on your player object. So just try accessing it like so: p.GetComponent<SpriterDotNetBehaviour>() This will at least give you the correct reference to SDNBehaviour. Hope that helps
  19. How exactly are you trying to instantiate it? Code please
  20. I think character maps solve most of the things you mention here and they're already supported in SpriterDotNet.
  21. I export the scenes in a json format with a bunch of properties for every object (like transforms sounds, layers, etc...) and read that in MonoGame. As for the assets, I just save the paths to sprites/sounds and have the same assets structure in both the Unity editor and MonoGame runtime. Nothing too complicated but works really well. I absolutely agree. MonoGame is "just" a framework for multi-platform DirectX/OpenGL rendering which it does really well. That means you have to tell it what to draw and where. That also means that you have to implement / integrate 3rd party tools for physics, entity component systems, scene graph, etc. Which is something I really like because I fell like I have total control of what's going on in the game I'm making. I actually started with Unity since everyone was saying it's basically promised land for anyone making indie games. After 6 months of work I switched to MonoGame and didn't look back. However, I'm a hardcore developer and I understand it might not be for everyone. @Ecu My suggestion is to try both and see what works for you.
  22. I'm using MonoGame and I've been really happy with it. I takes a bit of extra work initially but I think it pays off in the long run because it is just a good tool that doesn't force you to do things a certain way (+ it is open source). As the IDE, I'm using Visual Studio Community which comes with integrated Xamarin. And of course, the SpriterDotNet MonoGame variant for all my Spriter animation needs. As for Unity, I'm still using it but only as a level editor and I find it absolutely fantastic in that role. About the (really good) points @Dengar made: The loading impact can be mitigated if it's done during (or just after) the scene load and not in the middle of running the game. As for the memory - I'm fairly certain that dynamically loaded things have the same memory footprint as the ones instantiated from prefabs, at least while you only have one instance. With multiple instances prefabs work as a Flyweight Pattern which is something you want to do with dynamically loaded ones as well. In a similar fashion, SpriterDotNet uses ScriptableObjects to share common data between different Entities from the same Spriter file. Hope that helps
  23. The generation toggle sounds like a good idea. I'll implement it along with the other thing. Just as a heads up, it probably won't happen any time soon since I don't use Unity as the game dev platform of choice anymore.
  24. I think you could reuse at least 90% of the code from the importer and just get rid of the UnityEditor specific stuff which is something you don't really need for runtime creation. This actually gives me an idea - it would probably be good to extract that functionality in the library itself and just use it in the importer.
×
×
  • Create New...