Jump to content

Dengar

Members
  • Content Count

    189
  • Joined

  • Last visited

  • Days Won

    7

Dengar last won the day on October 18 2017

Dengar had the most liked content!

About Dengar

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ok so I thought I made this clear but uhhh... Maybe I should just spell his out. I'm not actively developing this thing anymore. I haven't been for quite a while. I originally just started it as a mental exercise project hoping that it would inspire others to contribute as well but so far I've only had a handful of pull requests or noticeable forks. I ended up running into a lot of problems and lacking outside input on the project just kind of made it... not fun.
  2. I honestly don't know. I never really got why some animations translate normally but others don't. Nobody's been able to tell me either.
  3. The order in which assets are imported can be unpredictable. It's easiest if you import the images first and then the .scml file. Or if you're lazy like me, import everything, then re-import the .scml.
  4. I'm under the impression that ThunerSkelett is expecting to see animations as separate files when the animations are actually part of the metadata?
  5. I haven't really worked on this project in ages. And to be honest, I don't intend to work on it in the near future either. It was just a little pet project to see the extent of my scripting abilities. Also I have gotten a bit fed up with Unity. It just doesn't do the things I want it to in the way I want it to do them. As I said before though, the code is out there for everyone to tinker with, I made it as understandable as I possibly could, and I'm willing to answer any questions I can. I still handle pull requests as well. I think SpriterDotNet is fully featured though, including Character Maps. It requires a bit more programming than Spriter2Unity does, but if you're willing to learn how it works. I wrote a little addon for it too that allows you to use the Animator's state machines. EDIT: I just realised Loodakrawa sent you here from SdN. I'm sorry I really couldn't be more help. While the basic features were easy enough to implement I just kept running into all kinds of glitches that are beyond my current skill level. Such things get frustrating after a while.
  6. Oh right, I forgot about this. I honestly don't know whether or not it affects performance. I don't think it does in a significant way. If commenting it out makes your animation work properly and you won't miss out on anything, should be fine if you leave it like that.
  7. Sure, I could point you in the right direction. I am, however, quite busy this weekend. You can poke me again later during the week if you want.
  8. What about SpriterDotNet? As far as I've heard it's fully featured and has a guy actively fixing the little bugs that arise. I've made it no secret that I'm not actively developing Spriter2Unity anymore. I do still review pull requests.
  9. Boneless sprites are not really a situation I thought of when designing the tool. It's possible that it doesn't work correctly if there's no bones.
  10. When I said "programmer's paradise" it means literally a paradise for a programmer. Someone who focuses more on visuals or designing the game itself might not find it very appealing. That said, if you want to improve your programming skills and learn to program a game at its base level, I can't think of a better framework tbh.
  11. The main advantage of using an actual prefab (which can't be constructed at runtime) is the fact that prefabs are serialized using Unity's native serialization system. All Unity assets are deserialized at the actual engine layer (where the engine does its job) rather than the scripting layer (where all of our scripts are run). It stands to reason that Unity's deserializer is more optimized than anything we can come up with on the scripting layer. Instantiating a preconstructed prefab will most definitely be significantly faster than first creating a GameObject from scratch, add components to it, and then populate the components' fields with values read from an XML file. MonoGame is a programmer's paradise, really. It gives you absolute control over absolutely everything. The downside? It's not a game engine at all. You will have to write all the rendering and physics code yourself (or borrow it from an open source), and there is no editor at all, let alone a fancy one like Unity. That said, I much prefer it over Unity for 2D games since Unity does many unnecessary things that you can't really turn off. And SpriterDotNet also works with it. @loodakrawa You use Unity as a level editor? What do you do then? Write the assets to disk as text and then import those into your MonoGame project using a custom importer?
  12. It's been a while since I fiddled with anything Spriter or Unity, but either way, the process for creating a prefab from a script is basically. 1) Create an empty GameObject 2) Instantiate supporting objects (like the data container ScriptableObject that SDN.Unity uses) 3) Add Components to the GameObject 4) Set the values in said Components 5) Save the GameObject as a prefab 6) Save supporting objects as assets 7) Delete the GameObject Steps 5 and 6 are possible at Editor Time only, and I'm fairly sure steps 1 through 4 don't even need any Editor code. You would need a different "Step 0" (acquiring and reading the .scml file) though. Regardless, creating a spriter object at runtime would skip steps 5 through 7. A word of caution though, from my understanding, there would be two possible problems, and solving one could possibly cause the other. Although there's probably fixes for these, I can't think of any right now. Basically, the first issue is that reading the .scml file and creating the GameObject takes a while. Depending on the size of the .scml and the amount of .scmls you are trying to read, this might not be a huge issue. The second issue has to do with the fact that the resulting GameObject can't be saved as a prefab at runtime, since this requires Editor code. The only way to retain easy access to the spriter object is to keep it in memory the entire time. Depending on how often the spriter object is used in your game, this might not be a huge issue. The first problem can be solved by only reading the .scml file once and keeping the GameObject in memory. The second problem can be solved by destroying the GameObject when you no longer need it and rebuild it from the .scml when you need it again. So... yes, the solution to one problem causes the other. That being said, depending on how your game works, one of these problems might not be a huge issue. Of course there might be something I'm missing here and there's not really that much of an issue. If you want to speed up the read process, you could alternately import the .scml data once, then save that data to a faster medium, such as MessagePack. It's sad that Unity doesn't let you use its own native serialization system at runtime, that would be ideal. Oh and there's also the issue of using external image files. I mean it's quite possible, but the code for reading them is different (and possibly slower?) at Runtime than it is at Editor Time.
  13. I'm sorry to say this but... I haven't the slightest clue. I've never heard of this before.
  14. Well, the problem is in the scripts that the importer attaches to the prefabs. Like I said, the script can make invisible things visible, and visibile things invisible, but it seems to forget to do so for things that start out invisible.
×
×
  • Create New...