Jump to content

Mike at BrashMonkey

Administrators
  • Posts

    2,968
  • Joined

  • Last visited

  • Days Won

    228

Everything posted by Mike at BrashMonkey

  1. Also, I'm seeing very strong tallent here discussing/debating the methods of diferent technology and work flow. You all do great work, but find diferent things more important. You all make good points from your point of view, and based on your individual priorities. The great thing is Spriter will soon allow each of you to comfortable and quickly work with your desired methods and even use the other methods you normally would not when those become preferable for the specific task and technical requirements at hand. Spriter benefits from all of your input and fantastic example animations... as does the community by being inspired by your work and learning by your examples and discussions of technique... even debates are useful, just please don't make them personal or "guess" or "project" personal character atributes onto the people you have differing proirities from, and just stick to clean, logical points and counterpoints pertaining only to techniques, work-flow, use of technology and feature trade-offs etc. And, in my opinion, even when it really rubs us the wrong way..when someone really seems to have the wrong aditude wen expressing their priorities and desires, its almost always best to not address that aspect at all...if you think they are wrong from a factual, technical, logistical standpoint, prove it politely, calmly and only with points or counterpoints...you'll come off smelling like roses, and will never have to backtrack or "eat crow" for having jumped the gun when a particularly stressful day makes your buttons all too easy to push. ;) cheers, Mike at BrashMonkey
  2. Hi everyone, Just to clarify a few things about our position on things: Indeed, this is a thread for feature requests/suggestions, so mentioning, directly comparing, and even being completely biased towards and/or mentioning other tools here are all completely fine as far as we are concerned. (not that I'm accusing anyone of being unfairly biased, just saying even that is fine, so long as there's no silly flame war starting language and personal insults going with it) We definately do not have or support any kind of "you can't mention our competitors" type of policy... we feel products should stand on their own merrits in broad daylight, without the worry of direct comparisons etc. We love and always planned on supporting all the cool bendy-warping stuff from the start, BUT its critical to keep in mind this stuff takes a considderable amount more processing power (especially when tweening etc) and many platforms/ game engines might not be able to support it, or, if people make every animation for every object on screen use it, they might contribute to unacceptibly low fps on some platforms. This is why we waited until all the non-warpy stuff was supported first...its universally useful. Using full frame rendered PNG's for sprite/character animations will always have its place, but its a massive trade off: No tweening and a drastically greater usage of memory. You also can't easilly or efficiently do all the cool costume, weapon, armor swapping thing either...but it does require less processing power.
  3. Sounds fantastic. Looing forward to it. cheers, Mike at BrashMonkey
  4. I think you'll be pleasantly surprised with b6 and especially Spriter Pro 1.0, bwwd. And I personally cant wait to see the awesome stuff you'll be able to do with it. cheers, Mike at BrashMonkey
  5. Welcome to the Spriter community, sonder! I'm just an artist, but what you propose sounds potentially very useful for many potential Spriter implimentation developers.. Anything that can help people get Spriter supported in their game engine of choice, and in a tidy and optimized manner sounds fantastic. Thanks so much for sharing your efforts with the rest of us. cheers, Mike at BrashMonkey
  6. Hi Tom2013, Thanks for supporting Spriter and for the kind words. About your technical question, have you seen this yet? http://www.brashmonkey.com/ScmlDocs/ScmlReference.html If that doesn't supply the answers you need, you can always email Edgar directly at Lucid@BrashMonkey.com to hit him up with specific questions of the forums don't provide a quick response. Edgar's a very helpful guy, but is typically spread very thin, focussing on getting the latest build out so doesn't check the forums as often as his emails. cheers, Mike at BrashMonkey
  7. Let me clarify, Its very possible Spriter support (the scml plugin) will be a default part of C2, but NOT Spriter itself. There is always the free version of Spriter as well, so C2 users will be benifiting greatly from Spriter support at no extra charge unless they want to take advantage of Spriter's Pro features, our art packs etc. cheers, Mike at BrashMonkey
  8. hi needyourdisease, I look forward to creating more advanced technique themed tutorial videos, but unfortunately I wont have the time for quite a while. Once B6 is out I'll need to redo most of the current tutorial videos to incorporate the new features etc. I'm hoping in the mean-time someone else knows of some good generic bone animating tutorials they could link you too. cheers, Mike at BrashMonkey
  9. really awesome stuff bwwd! cheers, Mike at BrashMonkey
  10. Hi everyone, To clarify a little, Spriter was always intended, even at its earliest stages in concept and development to be a tool for export and use in any and all development platforms. Construct and Construct2 were its birthplace because Edgar and I were both long-time members of the community and have great respect and apreciation for the level of flexibility and ease of use that scirra's authoring systems offer. And while Edgar does have his hand in the development oh the Spriter plug-in for Construct2, it's developing rapidly due to Ashley's(the developer of Construct2) active participation and cooperation in making the plug-in and ensuring its as thoroughly and intuitively integrated into Construct2 as possible. For these reasons the it's highly likely Construct 2 will be the first authoring system with full and perfectly integrated Spriter support...but will not be the last. And, in a sense, because its being developed in cooperation with scirra, and will be a free and built in part of Construct2 (when its finished), its not exactly or simply an "official first party plug-in". We hope that we will be able to follow this development model with many other authoring systems. We're confident that what we'll be able to demonstrate when Spriter 1.0 and the C2 plug-in are finished will entice the developers and communities of many other authoring systems to take such an active roll in implementing Spriter support, and Edgar will then have the time to take an equally active roll in their development. cheers, Mike at BrashMonkey
  11. Hey lovespriter, Sorry if this is the first reply to this, as I could have sworn I replied to this post months ago. :( Anyway, I hope you were able to get some assistance...if not, you can always email Lucid@Brashmonkey for specific questions about implementations and file-format.. Also, fret not, once Spriter Pro1.0 is released, we'll switch focus onto helping make sure all major authoring systems support Spriter as quickly as possible. Also, a finished version 1.0 with all features should really increase the drive amongst the developers and communities of each engine to finish the implementations. cheers, Mike at BrashMonkey
  12. Sorry it seems you're not getting the answer you're after, Mafiy... Did you try and contact the specific developer(s) of the current libgdx Spriter implementation? best of luck, Mike at BrashMonkey
  13. Thanks for reporting the issue, sunkai. We'll look into it when we get the chance. cheers, Mike at BrashMonkey
  14. Hi monumentalcorpz.com, Have you tried Spriter with this windows 8 feature turned off? It seems extremely likely this is the issue, and as the OS has no way of hijacking software and somehow making the full UI work at the changed scale, its only changing what it can...easy things like font-sizes..thereby causing the issue. There's likely no sensible way we can alter Spriter to fully support this feature. I suggest if you want EVERYTHING bigger and to still work and fit together properly, you'll have to reduce your monitor resolution settings. I'm just an artist though, so if anyone knows I'm wrong, please do set the matter straight. cheers, Mike at BrashMonkey
  15. One of my all time favorite songs! LOL. Nice work. I'm very glad you're enjoying the software. Many great features and workflow improvements yet to come. Thanks everyone for your patience. cheers, Mike at BrashMonkey
  16. Hi Pete, Thanks for reporting the issue...we've not yet able to test Spriter on all the variant versions of Mac OSX and apparently each version can pose specific compatibility issues...so its very useful when users such as yourself let us know when there are specific issues on specific versions of OSX. Things might get easier once the majority of people switch to http://www.apple.com/osx/ because it's free. In the mean-time, we'll see what we can do, but can't promise how soon we can resolve the issue specific to Mountian Lion...In fact we've not gotten similar reports (that I know of) for this issue, so it might be something other than the operating system version... Lastly, I assume "A5" is a typo and you meant "B5", right? (As A5 would be a very old version of Spriter ) cheers, Mike at BrashMonkey
  17. Hi Isaiah Sherman, Spriter's timeline is based on time, not any specific FPS, because you might make animations with Srptier meant to be played back on a variety of platforms, all capable of reaching different frame rates. Animating based on real time and not a specific FPS insures the animations will keep the same timing no matter how powerful the system is that's replaying the animations. Therefore, in Spriter if you want to make the animation last 1 second, then that's the default, make your last frame at the end of the time line and your first frame at the start of the time line. That said, we understand many people are used to creating animations based on specific FPS or bight have a very specific FPS required for the final game... for these reasons we'll be adding an FPS mode to the time-line with will enforce any FPS you set it to and adjust the timeline "notches" accordingly. We can't guarantee how soon this feature will be added though, as it is necessarily a lower priority than the specific features remaining for the release of version 1.0. cheers, Mike at BrashMonkey
  18. Hi sunkai, Thanks for the bug report. Can you please let us know what operating system you are using Spriter on? cheers, Mike at BrashMonkey
  19. No problem, Glad you have the latest build. New one coming soon...but it will be released in the forum only for a few days to make sure the community helps us find any important bugs before we make it the new official build. cheers, Mike at BrashMonkey
  20. Thanks for reporting the feedback blazah99, Of course all such issues will dissappear in a matter of time...hopefully for this user he'll give Spriter another try once its out of beta and once the Flash Builder support is fully working. cheers, Mike at BrashMonkey
  21. Thanks for the bug report sunkai. cheers, Mike at BrashMonkey
  22. great bug reporting guys... keep them coming and Edgar will take care of them as soon as possible. cheers, Mike at BrashMonkey
  23. There will be a very easy way in a future build, but not likely the next release. -Mike at BrashMonkey
  24. Nicely done. Also, welcome to the community and thanks very much for supporting Spriter! cheers, Mike at BrashMonkey
  25. Hi Zeldafreakneo, Spriter is a universal tool for making real, tweened animations that could be used for virtually any modern platform or authoring system, so by default (and for now it's the only option) the timing is completely independant of FPS and is instead based purely on fractions of a second... depending on your computer's speed, or the speed of your game-engine and the target device, the FPS at which the Spriter animations will be played back might be very diferent, but the duration and timing of the animation should be identical across the board. For example, no mater what the FPS is durring playback, if you set a punch animation in spriter to take 1 full second, with the fist reaching full extension at the half-second mark...this will be true no matter what the FPS. Eventually we'll likely add a way to switch Spriter's timeline to an FPS mode and force Spriter to play back animations at a given FPS, but can't guarantee how soon this feature will be added. I hope this makes sense and answers your question. cheers, Mike at BrashMonkey
×
×
  • Create New...