Depending on how many objects you have it doesn't necessarily auto-center to where the prior object was. It tries to,I see that but quite frankly in my bigger project with closed folders and such, it seems to scroll towards the middle of the families. The example isn't that bad, but it does show off the issue.

Project Window bug

Just move a sprite into a folder and watch the project window move.

For an issue that's easily reproducible and is IDE related?

Well the question is what effect will that have on the engine?

For example how will pixel round deal with it, or even flipping.

Anyway this is actually the one argument against using power of two images.Um no. I use power of 2 images. Problem being that you can't have a 16x16 square fit into a hole that is 16px wide because the way it calculates collisions.

So in order to get a 16x16 box into a 16x16 hole, I have to make it less than 16x16. In order to do this without it moving at higher resolutions, pixel rounding must be on, and it must be very slightly smaller than the size you need.

This is really more of an argument for a different collision system, but since that isn't going to happen I'd like to settle for the ability to edit the BBox vertices up to at least the 2nd decimal place. You can place them manually with the mouse between pixel so I don't see the harm in letting you do it via keyboard.

Hmm, seems so much smoother in yours, but you are also dealing with larger objects and slower speeds.

Well I got it using manual input. I really wanted it to know when the player is moving and not obstruct the player so I didn't have to code "If "Down" is down" and such. Guess making a small resolution retro style game is a bit difficult in C2 atm :P.

Well it works for now, thanks for the help :3

Project Window bug

Steps to reproduce:

1. Have lots of objects and families in objects

2. Move 1 object to a subfolder in the projects side window

3. Watch the Projects window scroll to the middle or lower, way far away from the previous spot you were at

Observed result:

Projects window scrolls when moving objects

Expected result:

Project window should stay at the location where you had the scroll before releasing the mouse.

Operating system & service pack: Win7x64

Construct 2 version:r135

For smaller graphics, I have to set some collision boxes to be in the middle of the pixel itself. C2 has no issues handling this, however the process to do so is tedious as I have to enlarge the sprite, adjust the collision box, then shrink the sprite back down.

What I am suggesting is the numerical editing of collision box vertices to at least 2 decimal places in (instead of 1x it can be put in as 1.5x)

Edit: original said BBox, not ColBox. BBox is image border, ColBox is the modifiable collision box, which I was intending.

I'm trying to create a top down puzzle game, and one of the objects is supposed to be a block that the player can push.

This block has to block movement, and be pushed at the player's maxspeed until it hits something it cannot move through

I have tried many different ways but nothing really works. What's causing most of the issue is the player, upon collision, stops movement. Well that and a few other issues.

So for a top down puzzle game with a pushable block, do you have any ideas how I could impliment it?

With 8Dir, you only can modify speed. This is fine unless you have a static square that does not rotate, which then means modifying speed only modifies the vector the sprite is always facing.

What I suggest is the ability to modify Vector X and Vector Y within actions.

Hopefully we can get some word from Scirra about that. Hell, I'd settle for more information about how Nintendo is going to handle it and keeping it up to standard.

Ashley

Well you could always have it as an optional mode in which is recommended only for use on upscaling a low resolution window.

Sounds like a lot better idea than the current Pixel Rounding system for retro/pixel style games.

Ah, must've missed that thread somehow.

Thanks for the news.