Ruskul's Forum Posts

  • This would for sure be a great official feature!

  • Yes, this bumping is very annoying to my team, we ended up transferring collision to additional single object collision boxes to work around it. It would be nice, trusting what you say, to implement a solution in the engine.

    Well... its still not a good solution, it changes the way the rest of physics works and will still sometimes trip on those seams. It could work for some things, but I wouldn't change a whole project for it. Tell Ashley you want proper collision edges. I did, he didn't care. But I think if enough people yammer about it he will eventually officially include more box2d features. I was under the impression he was waiting for a new build before adding them. He got his new build and then still didn't add them. I even gave him some code for fixing some bugs and suggested adding of a few features that I also had code for... but alas... Ashley is a very busy man and has way too much on his plate. c3 eh? I'm hoping!

    Cheers

  • Construct 2 raycasting plugin

    Welcome back I guess?

    ~Sol

    haha yeah, that is a sweet plugin. Unfortunately, I've spent the last month doing the hard work of getting my game switched to unity. Now that it is there, there are a number of benefits I won't through away after all that work.

    But this plugin is great. I had a discussion with Ashley a year ago about lack of useful collision information (surface normals, distance, etc...) but I guess he didn't think it was useful.

  • Frankly, Ashley should have included this 5 years ago. The lack of this feature is the #1 reason I am currently developing in unity instead of c2. Great addition!

  • I know this has been discussed at some point here, the obvious solution is to use an edge collider... but we all know that doesn't exist in construct2 box2d implementations... but there is another way around it. You can change min penetration without penalty to 0.

    This should be an option. It has its price and so shouldn't be default but it would fix all those game that roll objects across what wshould be a smooth surface and get little bumps.

    If you like to edit code you can change the setting in the behavior for physics.

    I learned about this while using unity today and then confirmed. and I came running back here as fast as I could to share the news for any who care. If only c2 had raycasting I would have never left in the first place (I need to get the angle of surface normals... Which is not in my mind a luxury but a necessity in games - especially when trying to role your own platformer engines on a routine basis).

  • http://gamedev.stackexchange.com/questions/18787/how-does-one-avoid-the-staircase-effect-in-pixel-art-motion

    This has a fix, found it while working with unity. Th op also does a better job explaining the problem too.

  • I have question, if that is ok.

    I read 'fps style'. fp.. stands for first person ....

    Meaning the camera should (since its 2D) be on the players position and look in the direction that the player is looking ?

    Well, I mentioned fps as first person shooter because that is an example use that I think everybody would get right a way... and yes, I may have been using construct 2 in a pseudo 3d capacity (think old 3d games)

    But the last statement you made could be another use. I think alot of games prefer not to be spinning because it is nausea inducing in the top down look in the direction as the player... human eyes don't track rotation like that and so its not as useful... but could still have its uses.

  • 99Instances2Go

    whats the n^2 rule?

    ...and I'm confused... what would x +=x%2 do to change the stair stepping... I didn't try it but I don't understand why doing this would change it?

  • The mouse plugin has no expression for tracking x and y axis! You know, you can of course save teh last position of the mouse and get the difference but that only works until you hit the edge of the screen .

    What would you you need it for... well... my game for one thing as I am using it to spin the camera fps style

  • Couldn't you just create a family and put all the objects you want in them, then give it instance variables to record their x/y positions and compare them each frame and do any corrections if necessary?

    So you'd shift them at the end of the events, and then restore their positions at the beginning of the events.

    Idk.. just an idea i had.

    But yeah, I only make low-res pixel games, so this sort of thing would be important to solve, as well as any other jitter related issues.

    Thats 1 solution in a nut shell, but can be performance costly doing that via events depending on the type of game you are making.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Well, what feature would help with this and how would it work? Things like uneven scroll updates are due to maths, not the technology.

    TLDR from previous post:

    You could have an option that when enabled the following would occur:

    compare the difference between the actual position of the object and its new position. (dx,dy)

    if (dx > dy) then only update the render position on the y axis if x is also updating

    else vica verca.

    does that make sense? You would have to track the rounded render positions and were they are force to.

  • Well, what feature would help with this and how would it work? Things like uneven scroll updates are due to maths, not the technology.

    That's just it though, I've been thinking on and off for a year or so on this topic and really haven't found a good solution. Many objects have to be synchronized (camera, player, etc...) so that makes it a hard part to make part of the engine right? I mean how is construct supposed to know what you have moving and whats not and which moving objects matter. The only thing I could figure is that some sort of behavior could be applied that looks at the objects last position that it rendered to, and its new render position. If the difference between oldx and newx is greater than oldy/newy, then it only updates y render position when x render position updates and vica versa. This can eliminate stair stepping mostly... I have a project from a year ago that does this... I just stopped doing it though because via events it starts to take a toll setting and resetting object positions twice a frame, storing the old render position and the "real" position... and so on- especially when you have many dynamic objects. As it stands I don't think there is a way to even tell the c2 renderer to render this sprite at an offset (you could do that via an effect I suppose... but again performance can tank if you have many actors) which would be helpful (actually it would be cool to be able to change the objects render setting in game - you know, draw it this big, at this offset, at this color, using this blend mode (x,y,sx,sy,rgb,mode).

    On a side, I was running a nes emulator on my laptop when I was talking about nes games... They have something going on like what I described above to ensure you get that nice pixel line instead of thicker stairstepping lines (like the middle image I provided)

    ---- My current practical solutions via c2

    In general, these days I turn pixel rounding off and then make sure I have my camera position make sure it is only updated if the actor it is following would have had a visual rounding. the stair stepping is usually only obvious when using lower resolutions. Or the character is moving at a steady angle.

    This is a stupid way to do it but I also sometimes make pixel art, scale it up in Photoshop using nearest neighbor (to like 4x or 6x), then I run the game with linear and no pixel rounding at a decent resolution. Its not as crips as pure pixels but You get amazingly smooth everything including scaling the screen, and zooming in and out. It takes longer to make all the assets, and it does less well performance wise, and if you use tilemaps you have to fix that... but you get the gist.

    ------

    Of course, it bears noting as you said, this isn't a c2 specific problem but, as you noted, a problem with trying to emulate crappy hardware of the 80s on a modern platform. Unity has the exact same problem... only it can get worse because you have to deal with fixedUpdate and regular Update syncopation and how the game interpolates position if you are rendering faster than updating fixedUpdate,

    Sorry for the Long read, I'm trying to be brief.... lol

  • https://dl.dropboxusercontent.com/u/11449416/TestsJitterDemonstration.capx

    The red pixels are bad... they jitter, they use defualt pixel rounding... the green pixel is cool... he knows he shouldn't be jittering around so he doesn't... stupid red pixels

  • - I round my camera to what ever it is following, but If I change objects, I make sure I change them back before altering there positions. This is where I wish the engine had an option for it because updating all dynamic objects at the end of all your events before a render and then undoing those changes is a huge performance drain. If you don't undo the change then you are literally moving those objects which can cause problems.

    If you have a "real"velocity expressed as a float and then calculate a "facade" velocity that works nicely with everyone that is calculated every tick based on dt... The biggest thing Iv'e noticed is that you need to have the larger component of velocity (x/y) be evenly divisible by the other. I don't think moving 1,1,2,1,2,1,1,2,1,2... and so on is as bad as visually rounding just x this tick and then just y the next tick... (x,y,x/y,x,y,x,x/y)... as this gives a literal stair step movement look instead of a diagonal look... anyway...

    I'm a bit surprised that Ashley doesn't understand this. He certainty is smart enough, maybe he isn't thinking about it from an asthetic standpoint and only programming?. He understands that it does what it does, and why it does it, but doesn't see the problem with that solution... after all, that IS what you are asking for with pixel rounding. I understand where he is coming from, I think . But if he would compare, as you mentioned, the arcades, and early consoles to C2, he would notice that x/y never NEVER stair step. You can run an emulator at 0.1 speed and see Mario update x/y without the smaller component ever being syncopated. You can achieve this on a modern system with variable frame rate... you just have to emulate it mathematically. The place for that is inside the engine and not the event editor.

  • Know what I'm talking about?

    i.e... Jitters... You know, when an object rounding to the nearest pixel clicks to a new x coordinate one tick and then a new y coordinate the next and back and forth. Rarely does the object update both x and y simultaneously at lower velocities. The result is a sort of jittering stair step movement. Once the object is moving fast enough (say 200 pixels per second, depends on resolution as well) the effect is much harder to notice. But it is super obvious when a platformer reaches the apex of a jump or a top down guy is running diagonally... and so on...

    I spent some time with the nes and noticed this doesn't exist. If an object needs x updated more often than y then y only updates with x. Basically it won't alternate between the two... even if it makes mathematical sense. Now, I know the nes had a fixed frame rate.... but it did have sub pixel positions (though I only think 4). But either way if my object was at 0.5,1 and I started making it move at 1 sub pixel per component per frame, it would still update (visually) only one component per 4 frames and be alternating between the two and giving that jagged jitter movement look. But thats not what happens on the nes... Something goes on to ensure that x/y are updated together or that only one gets rounded while the other has to wait for the next update time.

    Does anyone have any idea how this could be achieved with a variable frame rate... Iv'e messed around with a few ideas but I am curious if a.) anyone else has a system they use to mitigate this... and b.) why it should probably be a feature in project settings as it would be way better for the engine to deal with this.

    ------------------

    Because some people can't visualize: Check this out. Red pixels "Jitter" sometimes because they stair step. The green pixel doesn't.... cause he is cool, so cool.

    https://dl.dropboxusercontent.com/u/11449416/TestsJitterDemonstration.capx

    Pixel paths and rounding: what this means for you!