Scirra, Cropping images RUINs image poins etc!

Hi everyone,

Sorry to be a drama queen. I love Construct2 beyone belief and think most of it is designed flawlessly.

It's just killing me that it seems I have to leave images with massive padding around them if I want image points or collision poly shapes to be outside the actual used pixel area of a Sprite image.

Am I missing something? To me, this is an insanely arbrirtay and horribly wastefull issue in an otherwise brilliant tool.

Please tell me I'm just doing something wrong. :(

Thanks,

Mike

I have no problem dealing with sprites using blank areas, instead of a problem, I prefer this way because when I import my GIFs, they are with huge blank areas around, where I draw some different frames using that areas.

Also, your animation points and collision areas can have the same relative origin, making easy "set to all animations" and avoiding bugs with collision masks with different sizes, changing then on the run time, putting your player inside wall, for example.

Another thing is about make points go out the frames, if it's your case, why you just don't make a math to track the desired point relatively to a central point?

I think we're talking about two differnt things. You do want to crop all your sprite frames when you're done to save texture space, memory, file-space, load-time etc right?

If so, you dont want this to RUIN half of your image points and collision shapes and ruin your game, right?

Is it me, or does cropping currently ruin the shape of collision polys and image points if they are outside the "safe area" where theres actually image.

I think we're talking about two differnt things. You do want to crop all your sprite frames when you're done to save texture space, memory, file-space, load-time etc right?

If so, you dont want this to RUIN half of your image points and collision shapes and ruin your game, right?

Is it me, or does cropping currently ruin the shape of collision polys and image points if they are outside the "safe area" where theres actually image.

About the issue of cropping inside the editor I really said nothing about, I just concerned about avoiding the issues it can make, and it make sense, one time you change the sprite size by cropping it and all the frame points and areas points are relatively to a origin:

Also, your animation points and collision areas can have the same relative origin, making easy "set to all animations" and avoiding bugs with collision masks with different sizes, changing then on the run time, putting your player inside wall, for example.

I workaround these type of issues just editing the images directly, using software like Fireworks, who can do batch processes, and with C2 closed, then opening C2 again.

Sometimes some adjustments are necessary, but it work well.

Best luck and I hope a solution for your problem too.

Again, I dont think you are understanding what I'm talking about.

So, you don't mind giant wasteful areas of blank space around each frame of each animation, hogging precious load-time and resources..hurting your frame rate etc?

Ideally Construct2 would have a project-wide "crop aLL frame images to remove unused space" option that users could use once when the game was finished in order to optimize WITHOUT ruining any image point locations OR collision shapes.

It is rediculuosly simple math to keep the correct position for image points and for collision shapes while cropping. That is no excuse.

are you talkin about having image points and origins outside the actual image? Thatd mean when you crop it of course its going to be outside the new area of the image and thats not valid no matter how you look at it. To have something like that outside of the actual area of the sprite of course your gonna have to have blank empty space around it

Says who, and for what reason? its just x,y coordinates, not pixels. There is NO reason it could ever be considered invalid.

— - if you are using r100 then yes. that was mention in the bugs area.

I have no problem dealing with sprites using blank areas, instead of a problem, I prefer this way because when I import my GIFs, they are with huge blank areas around, where I draw some different frames using that areas.

So for example you have animation of a bouncing ball.

Ball size is 32x32 but you will keep all your sprite animation frames on 512x512 with transparency around cause it makes your image point stay where it should be?

Thanks shinkan. Its great to hear that its a known bug. I was quite worried that was an intended change, which would have been a horrible idea.

You can place image points outside the image area. Only the origin and collision polys are bounded to the image area.

I can't recall off the top of my head why origins have to be bounded (I'm sure there was some reason), but it's very important for collision polys: a really huge optimisation in the collision tester is that it can immediately return with a "not overlapping" result if the object bounding boxes do not overlap, which is an almost instant test. If collision polys can go outside the bounding box, all bets are off and every single collision poly point has to be tested. That would be really slow, so collision polys are bounded to the object area.

Collision poly and image points are stored in texture co-ordinates - in other words, if the image size changes, all points and the poly scale accordingly. You probably want to make sure you crop before setting the collision poly, otherwise the collision poly will be scaled down accordingly too.

Ashley - that does not explain why the origin should be bounded.

Thanks for the clear explaination, Ashley. That does sound like a worthwhile optimization for most games with lots of sprites checking for collisions. being able to place image points outside the bounding box was the most important to me.

Please though, if there's no good reason, it would be hugely helpful to be able to put even the origin outside the bounding box..there are several animations in my current game project which require this.

sqiddster

Yes, if necessary I do a image 3 times bigger than the necessary for the currently frame:

<img src="https://dl.dropbox.com/u/47035927/00%20-%20EQUILIBRIUM/images/01weapons-sheet1.png" border="0" />

On this image, the origin and any other points are stored inside the image, where I do some sparkling effects.

It is rediculuosly simple math to keep the correct position for image points and for collision shapes while cropping. That is no excuse.

Also, you can make masks for your sprites and simple pin the animations on these masks, keeping the collision areas and points on the mask, and using the animations only for animation purposes.

Another question, you're wondering this for the Spriter plugin?

No, this is totally unrelated to Spriter.

I use rectangle (mask) sprites to control the player controlled platformer objects, but I dont want have to resort to using two sprites for every single enemy in a level.

I'm satisfied that the image points will b e fixed and will use tricks to get around the collision shape limitations as well.