Hi Everyone,

I need to make a crosshair (on a nonscaling, non paralax UI layer) that can stay perfectly locked on to(put itself perfectly on top of) objects which can each be on any of the other layers...and each layer has a different scale and parapax amount.

I thought I had it by using LayerToCanvas, but this only works with the projects "Fullscreen in Browser" mode set to "off". Any of the scale modes, the crosshair no longer lines up with the objects that its "locked onto"

Can anyone help make t his work?

Here's my capx:

LaterToCanvas Issue

An important bug. I have several instances of a tiledsprite in a fram, all set to invisible within the frame (not by an event, just as its setting in the frame editor in its settings)

And this causes Chrome to crash when I run it, without fail. Yet if I set them all to visible, the frame runs fine.

Thanks,

Mike

Hi, Awesome plug, but I'm trying to use it wit hte latest alpha build of C2 and it seems the animation always plays 1 frame per screen-update (super-fast) no mater what its set to.

Also, a suggestion: An event to change the x or y offset of the texture image at runtime would be amazing!

thanks,

Mike

For those who'd like the equation, its dividing its (current) height or width by the original (image) height or width.

It doesnt take too long to do this way, of course, but as theres a set scale action, and you can already retrieve layer scales, it seems missing and a bit inconvenient for retreiving a sprite's scale to be missing.

Hi everyone,

What formula would I use to get the current scale of a sprite, and why is this not a built in function to go along witt the set scale action? Or maybe I'm just missing something...

thanks

You don't want to use Construct2? Thats what I'd suggest. Cross-plaltlform support with good performance is getting more real by the day.

-Mike at BrashMonkey

pledged. Keep up the great work guys. The game is looking very fun.

-Mike

Hi BluePhaze,

This is Mike at BrashMonkey..

I'm glad Spriter is already prooving itself useful to you and look forward to the many features yet to come drastically increasing the advantages Spriter will offer. Thanks very much for the kind words and support.

Here is a link to high-res versions of Spriter's logo for anyone to use if they'd like: brashmonkeygames.com/brashmonkey/spriter/Spriter_Logos.zip

I (and a few other artists) continue to work on the first two art packs: (Game effects and Basic Platformer), but will not be able to finish them until Spriter itself is a little closer to feature complete... So expect the official release of the art packs to be either durring the release of Spriter Pro 1.0 or slightly sooner.

cheers

My best guess is the framerate is not good enough and the objects never detect collision with the floor...but thats a wild guess.

Hopefully someone with identical devices can look into it.

Hi Knudle,

This is Mike. Edgar (called ?Lucid? here on the forums) and I are the co-creators of Spriter.

Spine is indeed a lot like Spriter, in fact it was at least inspired in part by Spriter. To paraphrase from their comments, they were excited about Spriter and had been part of Spriter's forums but felt Spriter was taking longer than they wanted to wait and they worried Spriter would lack some of the features they wanted in a modular editor for the purpose of making their game project, so they decided to make Spine.

Here's some things you should know about Spriter when comparing the two tools:

1) Spriter is indeed taking longer than Spine to get to a version 1.0, but this is in very large part due to the intended scope and feature set we have planned for Spriter as well as our commitment to cooperation with the game development community during its development. An example of theses points is Spriter's data format which we took the extra time to make open from the beginning and co-developed with the community to insure the most flexibility it could offer while also insuring it would be very easy to add new features later without breaking backward compatibility.

While our next build (which is getting close to being released) has a feature-set similar to that of Spine, we consider it and even the first version of 1.0 to be very much just the beginning of Spriter's development. Spriter is not just a tertiary product we're releasing on the way to making games, we are very dedicated to its continued growth, increased flexibility and useability. We both love designing and making tools which empower creativity and reduce the need for tedious aspects of game creation, and Spriter is the focal-point of that passion.

2) Even though Spriter isn't at 1.0 yet, we have always provided and will continue to provide a well-featured free version of Spriter with the ability to export the actual optimized Spriter data for use in games. You can download the current beta version from here :

BrashMonkey.com

Many people and game studios are publishing games with animations create with Spriter, and many more are doing so by the day.

3) I think this point is the most important. Full Spriter support for Construct is already in the works and is a very high priority for us. See here:

Spriter Plug for Construct 2

Both Edgar (Lucid) and myself (Brashmonkey) are long time Construct users and supporters. (Check out how many plug-ins, feature improvements and bug-fixes Lucid has contributed to Construct Classic). I'm not mentioning this to pander for community support, but pointing out that Edgar and I have always had full, easy, and extremely flexible Spriter support for Construct 2 (and classic) very much in mind from the very inception of Spriter. In fact, the original Kickstarter campaign release of Spriter was made using Construct Classic. Because we are making our games with Construct 2 ourselves, its most definitely in our own best interest to get and keep Spriter and all of its up-coming features fully supported in Construct.

As you can see, we've already begun working (with Ashley I should add) to not just add full Spriter support for Construct 2, but to do so in as flexible and optimized a way as possible...not just a quick logic-port of generic Spriter API to get it working...We want it working as best as possible, specifically for Construct...and as nicely integrated into Constructs plug-in UI as possible.

Procrastinator

Thanks for the kind words about Spriter's intuitiveness. It actually will be further improved in that regard after all the 1.0 features are in, once Edgar has the chance to put in all the mouse-over descriptions and first time user pop-up dialogues etc. Also, While currently Spine has a few features we do not, the next and future build releases will quickly rectify that.

Cheers,

Mike

I can't wait to see, BluePhaze. As a C2 user myself, I'm just as excited at the prospects of a finished Spriter and C2 plug!

cheers,

Mike at BrashMonkey

Thanks again guys,

The C2 plug wont be ready at the same time as the next build is released, but its one of our highest priorities once the build is out. In fact, one of the important features we added to this build (a small part of what was taking so long;) ) is the feature to auto-name all objects within Spriter so that importing Spriter projects into C2 will be much faster and easier.. it will even auto-name objects in currently existing projects which include objects that were not named.

Construct2, Construct Classic, and the Scirra community have been a big part of Spriter's birth and will definitely be a big part of Spriter's future.