0 Favourites

Problem with collision + zoom?!

This forum is currently in read-only mode.
  • I have made a small example of the problem:

    I have a small green 16x16 sprite named "Player" and a 16x1 sprite ("Detector")which is supposed to stop the player sprite from falling when it overlaps something solid. Both sprites are in a family called "Movers".

    Detector NOT overlaping solid -> Movers: Set Y to Movers.Y + (80 * TimeDelta)

    The layout resolution is 320x240 and it runs in a 640x480 window with 200% Zoom.

    The problem is now, that with the zoom, the Player sprite appears to be stuck in the solid ground 1 pixel. However, when you remove the zoom the sprite will be stopped correctly.

    Here is the cap:

    http://www.erikakempf.de/blessing/falltest009.cap

  • It appears to be correct to me, it's just that the edges are blurred because of the zoom. At least on my screen.

    <img src="http://i28.tinypic.com/2wg4r3o.png">

    I've had problems with blurred edges on scaled-up sprites and tiled bg's in the past. As a result I've decided that all my future projects will just be 640x480 or higher. It's just too much of a pain dealing with the zoom in that way. There are other problems as well, when you get into parallax and such. I'd rather just scale my sprites up 2x and then import them...

  • That's weird... here is how it looks for me:

    <img src="http://img291.imageshack.us/img291/7392/fallprobik6.png">

    And when I remove the zoom it looks right.

    Does anyone else get the same error?

    And deadeye, did you try it several times? Cause sometimes it works right with the zoom (very rare though for me), but mostly it doesn't.

  • Construct 3

    Buy Construct 3

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

    Buy Now Construct 3 users don't see these ads
  • I tried a few. It always looked the same for me.

    But I'm mad that yours looks all crisp.

  • Ok PixelRebirth here's the problem, "TimeDelta" its pretty much around 1,3 so it will be innacurate thus going over the solid. Instead use for example:

    Detector is not overlapping Solid -> Movers.Y + 1

    http://www.mediafire.com/?7vnxb9zim5b

    Edit: Ow yeah i forgot to tell, it's not a Zoom problem, well if its changing your Frame rate then Zoom is causing the Time Delta to change.

  • That would mean back to the beginning, since before all movements were just that, X/Y +/- 1.

    But I wanted to add TimeDelta so it would run pretty much exactly the same speed on all computers. At least that's the idea I got from reading the article about it.

    So am I right that I actually can't use TimeDelta for custom movement engines as it will cause some inaccuracy?!

  • Ummm i tried the "X/Y +/- 1" style with different FPS and it worked just fine.

    Edit:Ok now i get what you want... have to research more at this.

    Edit2:

    [quote:1fx2gnjd] Drawbacks

    This system can cause problems very low framerates. A game running at 5 FPS means a fast-moving object going at 500 pixels per second will be jumping 100 pixels every tick. This can cause problems with collision detection: if the object is small, it is possible it will "step" over an obstacle without registering a collision. Being aware of this can help you design your game to avoid this situation.

    * Very thin or small obstacles are more likely to be missed

    * If the moving object is large, it is less likely to miss

    * Slower moving objects are less likely to miss

    * Instant hit bullets with a small enough step will never miss a collision

    The Drawbacks of Timedelta.

  • What I understand from the TimeDelta article the issue with different speeds is mainly with the monitor refresh rate. And TimeDelta is meant to fix this.

    EDIT: Okay I just read your edit :>

    Anyway, I guess I will be using the "old" engine style then, which is pretty much the same I used for years with MMF.

  • You can keep on using timedelta, just make a "push-up" loop to get your objects unstuck.

  • Ok made with deadeye suggestion with "push-up" , its working not good at 1~25 fps, but on everything else its good.

    http://www.mediafire.com/?hwd0dhmnccl

  • You don't need timedelta for a push-up loop, and that's not a loop.

    Here:

    http://www.mediafire.com/?z41xtvizkez

    Added some key control too, for feedback.

  • deadeye. yours doesnt push it back up. it still overlaps.

    edit: also odd. editing your events list wont let me add a system command. O_o

    edit: i started a new .cap and when i add a family system seems to dissapear from the options on the add event in the event list. only groupings are "objects" and "familes". system is nowhere to be found.

    http://i18.photobucket.com/albums/b121/comeon666/system2.png

  • deadeye. yours doesnt push it back up. it still overlaps.

    Well, I don't know what to tell you. All I know is it should work.

    In fact, it does work. Look at this example:

    http://www.mediafire.com/?hvgox9gyvvz

    Walk sideways into the protruding block. You will be pushed to the top because of the loop.

    It seems to me it's not so much a matter of whether the object is actually overlapping, but whether the image is rendering properly.

  • Thanks for your suggestions guys!

    But usually I like to build the engine without the need to constantly push sprites out of backdrops they're not supposed to overlap. And it works, but only without TimeDelta.

    Doppel's example works sometimes. But most of the time the detector and the player sit on top of the ground. Which is what the event actually does, since you're pushing the movers family out of solid sprites when the detector overlaps.

    And if I go by logic the condition should be with the player that overlaps. Which is what deadeye did, but strangely, like cecil said, although the events seem right it still overlaps.

    EDIT: I guess deadeye is right. When I add an event

    player overlaps solid -> close application

    it doesn't quit the app when I just let it drop on the top, although it visually overlaps. But when I move it in sidewards, it ends the application.

  • When I add an event

    player overlaps solid -> close application

    it doesn't quit the app when I just let it drop on the top, although it visually overlaps. But when I move it in sidewards, it ends the application.

    Yep, that's pretty solid proof right there.

    Edit: By the way, I can see the overlap you're talking about when I change it to point filter instead of linear.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)