layer effect zoom bug

This forum is currently in read-only mode.
From the Asset Store
Simple and easily editable template for a dynamic camera that zooms in and out based on how far apart the players are.
  • If I have a layer with a layer-effect, or and object with an effect, it causes a weird offset problem

    I had a post on this already :

    scirra.com/forum/effects-and-zoom_topic49967_page1.html

    But I just now found out that this only happens for me when my applications "Window height" is over 1000,

    even then its not really noticeable until it gets over 1038.

    after that it just gets exponentially worse.

    if I go to 1500 its just insanely off.

    My default window size is 1680 x 1050, I was always setting the resolution of my application to such, so that's why I was having that issue.

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

    However in my post, with my cap having a resalution of 1680 x 1050

    clodius666 reported having the same problem with his current desktop res. at 1440 x 900

    tulamide had a Desktop res. 1920x1080 (32bit) and didn't have the problem.

    so I'm willing to bet that this bug is dependent on the users current desktop resolution.

    however the only people reporting it also had ATI Radeon cards.

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

    I was wondering if some people wouldn't mind helping me see if my hypotheses is correct on this before I post it on the bug tracker.

    you can set it up yourself.

    or get this .cap:

    ZoomTest

    And set the application resolution to your screen size, or past it. before running it.

  • Some example photos at 75% Zoom:

    <img src="http://img694.imageshack.us/img694/5854/goodlu.jpg" border="0" />

                              At 640 x 480

    <img src="http://img685.imageshack.us/img685/5585/baddj.jpg" border="0" />

                              At 1680 x 1100

  • Should they stay perfectly overlapping when zoomed? Otherwise I have the offset issue even at 1600x900 <img src="smileys/smiley5.gif" border="0" align="middle" />

    Edit: Windows 7 64bit

  • G-force 9800, same issue here.

    edit: 32bit, win7

  • It's not the layer effects, it's the combination of demands that provoke this error. With resizing disabled the display is forced to stay at 640x480 while zooming forces to show a greater or smaller area and somehow this leads to the unwanted effect. (At least that's happening to me, when I go past 1920x1080 without any layer effects)

    You don't have that issue when using the window- and sysinfo-objects for changing window sizes, but it is a hassle to fake a smaller display size in the window and keep the aspect ratio.

  • so its safe to assume its probably not a graphics card specific error.

    tulamide your right. It does still have the same offset effect regardless of layer effects, but it seems odd that if there is an effect, the offset worsens for that layer.

    I was playing around with my duel monitors with this ( one is 1360 x 768 the other 1680 x 1050)

    when just dragging the application window from one screen to the other (at a size of 1680 x 1000) there was no issue, regardless of witch was the primary display.

    But when i set it to show just the smaller window, then ran at the exact same resolution as before, the offset problem happened.

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

    when you use the window/sysinfo object to change the resolution it makes it smaller than max client resolution

    such as : my display high is 1050, and that is what the system info says, but when it changes my window size, it sets it to 1012 witch I take it is the safest resolution to run at before the offset happens.

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

    I'm starting to think maybe this isn't a bug with construct, just something that happens if applications are to large. So a deeper "bug" having to do with constructs "hardware-accelerated DirectX 9 rendering"

    If that's the case, people should Definitely be aware of it before releasing their game so they can make sure to mitigate it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • It really is hard to tell, where that issue comes from. But I never heard of any other application producing it, so it might be a CC-specific one.

    when you use the window/sysinfo object to change the resolution it makes it smaller than max client resolution

    such as : my display high is 1050, and that is what the system info says, but when it changes my window size, it sets it to 1012 witch I take it is the safest resolution to run at before the offset happens.

    I can tell for sure that setting the client size is pure windows api calls (I know that, because I implemented them). I guess Win catches the calls and somehow reserves some pixels for the task bar, if the height gets higher than the resolution. But that really is wild guessing.

    I'm currently testing a few other things related. Will report soon, found some crazy behaviors.

  • Actually, I've had this problem since forever, too. This is the sole reason Blight does not support other resolutions. I can't guarantee it will be playable at lower resolutions--foreground items move in the way, etc.

  • So this is what I found out:

    The issue occurs if the display size and the window client size don't match. This happens when you set the window size in the application properties to a value higher than screen size minus something (couldn't find out how much exactly is subtracted and why; it's 38 pixel in height for Bartosh, but 20 pixel on my FullHD resolution). It happens because Windows interferes and changes the size for the window, but Construct isn't aware of the size changing.

    For example, I set a height of 1080 in the properties. Construct will set the display height to this value also, but the real height is 1060. This difference of n pixel seem to provoke the zoom issue.

    There's a solution: I provide a cap showing a way of changing the size safely without using the application properties. You still can't set the window larger than the screen size (minus something^^), but who would want to do this anyway? But you won't have that issue anymore, even if you go past the screen resolution (it simply detects the "real" values, after Windows interfered)

    zoomIssueSolved.cap

  • Nice to see there's a way to work around this.

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