Johncw87's Forum Posts

  • A very interesting find! Well done!

    If you were to use a sprite as an effect to be randomly placed over certain areas of an image, but random enough for the player to appreciate the effect without it being too repetitive, then you may need that many image points. Names would be fine except when there are so many image points and since I wasn't going to use the points for anything else and may use them again with other similar image frames where you would need to rename them again, I decided not to waste time in naming them all.

    Not sure what kind of effect you are going for, but wouldn't it make more sense to use something like this?

    X = random(Sprite.BBoxLeft, Sprite.BBoxRight)

    Y = random(Sprite.BBoxTop, Sprite.BBoxBottom)

    Or, if you wanted a bit more control on the spacing, you can abuse integer math to align them to a "grid"

    X = floor(random(Sprite.Width) / 4) * 4 + Sprite.BBoxLeft

    Y = floor(random(Sprite.Height) / 4) * 4 + Sprite.BBoxTop

  • > Touch.Alpha gives the compass bearing, so you're using the wrong value here.

    >

    Oh, sorry... Thought that would be the right one to use...

    So, what expression would I need to use? I also tried Beta and Gama, but neither of them worked.

    Well, do you want just gravity, or do you want all acceleration?

    With acceleration:

    X = -Touch.AccelerationXWithG

    Y = Touch.AccelerationYWithG

    Just gravity:

    X = -(Touch.AccelerationXWithG - Touch.AccelerationX)

    Y = Touch.AccelerationYWithG - Touch.AccelerationY

    Then:

    Angle = angle(0, 0, X, Y)

  • This issue appears to be related to the names of the image points. If I rename them all, I can continue to add more. I renamed each one to "Imagepoint ##" where ## is consistent with the imagepoint index.

    I can't fathom why you would need that many image points, but regardless of how many you use, you really should give them meaningful names.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • And here's why.

    data.js object definitions from unmodified example:

    [
		["Player", 1, false, [], 1, 0, null, [["Default", 5, false, 1, 0, false, 754574662893683, [["player-default-000.png", 825, 0, 0, 0, 0, 1, 0.5, 0.5, [], [], 0]]]], [["Platform", 2, 684013238865744]], false, false, 461099846823012, [], null],
		["Sprite", 1, false, [], 2, 0, null, [["Default", 5, false, 1, 0, false, 639043081041614, [["sprite-default-000.png", 825, 0, 0, 0, 0, 1, 0.5, 0.5, [], [], 0]]]], [["Solid", 3, 227558398387300], ["Sine", 4, 717431858105516]], false, false, 251897685913489, [], null],
		["Sprite2", 1, false, [], 2, 0, null, [["Default", 5, false, 1, 0, false, 961475536146256, [["sprite2-default-000.png", 825, 0, 0, 0, 0, 1, 0.5, 0.5, [], [], 0]]]], [["Platform", 2, 399711601778041], ["Solid", 3, 383344487100023]], false, false, 619511337493328, [], null],
		["Text", 0, false, [], 0, 0, null, null, [], false, false, 599919735085155, [], null]
	]
[/code:3mxbgrbl]

data.js object definitions after moving the Player object out of the subfolder:

[code:3mxbgrbl]
[
			["Sprite", 1, false, [], 2, 0, null, [["Default", 5, false, 1, 0, false, 639043081041614, [["sprite-default-000.png", 825, 0, 0, 0, 0, 1, 0.5, 0.5, [], [], 0]]]], [["Solid", 2, 227558398387300], ["Sine", 3, 717431858105516]], false, false, 251897685913489, [], null],
			["Sprite2", 1, false, [], 2, 0, null, [["Default", 5, false, 1, 0, false, 961475536146256, [["sprite2-default-000.png", 825, 0, 0, 0, 0, 1, 0.5, 0.5, [], [], 0]]]], [["Platform", 4, 399711601778041], ["Solid", 2, 383344487100023]], false, false, 619511337493328, [], null],
			["Text", 0, false, [], 0, 0, null, null, [], false, false, 599919735085155, [], null],
			["Player", 1, false, [], 1, 0, null, [["Default", 5, false, 1, 0, false, 754574662893683, [["player-default-000.png", 825, 0, 0, 0, 0, 1, 0.5, 0.5, [], [], 0]]]], [["Platform", 4, 684013238865744]], false, false, 461099846823012, [], null]
		]
[/code:3mxbgrbl]

In case you haven't noticed, the order these are stored in matches the order in the XML 1:1. The ID numbers used in the runtime are the indices into this array. The object names only exist unmodified in preview. In exported projects, they are replaced with t0, t1, t2, etc.

Care to tell me I'm wrong now?

  • Changing the subfolder an object is in does not change the order in which they're stored in the XML file, or it's ID. You can look at the XML files to see this.

    Example project posted in this thread without modification:

    <object-folder>
  <object-folder name="New folder">
    <object-type name="Player" sid="461099846823012">
      <plugin id="Sprite" />
      <behaviors>
        <behavior-type name="Platform" sid="684013238865744">
          <behavior id="Platform" />
        </behavior-type>
      </behaviors>
      <animation-folder>
        <animation framecount="1" loop="0" name="Default" pingpong="0" repeatcount="1" repeatto="0" sid="754574662893683" speed="5">
          <frame duration="1" hotspotX="0.5" hotspotY="0.5" />
        </animation>
      </animation-folder>
    </object-type>
  </object-folder>
  <object-type name="Sprite" sid="251897685913489">
    <plugin id="Sprite" />
    <behaviors>
      <behavior-type name="Solid" sid="227558398387300">
        <behavior id="solid" />
      </behavior-type>
      <behavior-type name="Sine" sid="717431858105516">
        <behavior id="Sin" />
      </behavior-type>
    </behaviors>
    <animation-folder>
      <animation framecount="1" loop="0" name="Default" pingpong="0" repeatcount="1" repeatto="0" sid="639043081041614" speed="5">
        <frame duration="1" hotspotX="0.5" hotspotY="0.5" />
      </animation>
    </animation-folder>
  </object-type>
  <object-type name="Sprite2" sid="619511337493328">
    <plugin id="Sprite" />
    <behaviors>
      <behavior-type name="Platform" sid="399711601778041">
        <behavior id="Platform" />
      </behavior-type>
      <behavior-type name="Solid" sid="383344487100023">
        <behavior id="solid" />
      </behavior-type>
    </behaviors>
    <animation-folder>
      <animation framecount="1" loop="0" name="Default" pingpong="0" repeatcount="1" repeatto="0" sid="961475536146256" speed="5">
        <frame duration="1" hotspotX="0.5" hotspotY="0.5" />
      </animation>
    </animation-folder>
  </object-type>
  <object-type name="Text" sid="599919735085155">
    <plugin id="Text" />
  </object-type>
</object-folder>
[/code:2vqbv2n9]

After moving player object out of subfolder:

[code:2vqbv2n9]
<object-folder>
  <object-folder name="New folder" />
  <object-type name="Sprite" sid="251897685913489">
    <plugin id="Sprite" />
    <behaviors>
      <behavior-type name="Solid" sid="227558398387300">
        <behavior id="solid" />
      </behavior-type>
      <behavior-type name="Sine" sid="717431858105516">
        <behavior id="Sin" />
      </behavior-type>
    </behaviors>
    <animation-folder>
      <animation framecount="1" loop="0" name="Default" pingpong="0" repeatcount="1" repeatto="0" sid="639043081041614" speed="5">
        <frame duration="1" hotspotX="0.5" hotspotY="0.5" />
      </animation>
    </animation-folder>
  </object-type>
  <object-type name="Sprite2" sid="619511337493328">
    <plugin id="Sprite" />
    <behaviors>
      <behavior-type name="Platform" sid="399711601778041">
        <behavior id="Platform" />
      </behavior-type>
      <behavior-type name="Solid" sid="383344487100023">
        <behavior id="solid" />
      </behavior-type>
    </behaviors>
    <animation-folder>
      <animation framecount="1" loop="0" name="Default" pingpong="0" repeatcount="1" repeatto="0" sid="961475536146256" speed="5">
        <frame duration="1" hotspotX="0.5" hotspotY="0.5" />
      </animation>
    </animation-folder>
  </object-type>
  <object-type name="Text" sid="599919735085155">
    <plugin id="Text" />
  </object-type>
  <object-type name="Player" sid="461099846823012">
    <plugin id="Sprite" />
    <behaviors>
      <behavior-type name="Platform" sid="684013238865744">
        <behavior id="Platform" />
      </behavior-type>
    </behaviors>
    <animation-folder>
      <animation framecount="1" loop="0" name="Default" pingpong="0" repeatcount="1" repeatto="0" sid="754574662893683" speed="5">
        <frame duration="1" hotspotX="0.5" hotspotY="0.5" />
      </animation>
    </animation-folder>
  </object-type>
</object-folder>
[/code:2vqbv2n9]

Clearly, the player object has moved, and as such, the order has changed.

    As for "presumably" - yeah. No. Presumptions don't help solve the issue. Especially when they're not accurate.

    You reeeaaally don't want to go there.

  • >

    > > *quote snip*

    > >

    > > I didn't mean "behaviors" in the sense of C2 Behaviors. I meant functionality (through events) shouldn't be affected by what folder something is in. Poor word choice on my part.

    > >

    >

    > The events are only being indirectly affected. The functionality change isn't related to the events at all. You get different results because the behaviors (both platforms and the sine) evaluate in a different order. This causes the positions of the objects to be different than they otherwise would when the event sheet is evaluated, which then changes the result of the conditions. You can see this when the player 'lags' behind the other sprites. The platform behavior attempted to solve this problem by doing its move logic in 'posttick' while other behaviors use 'tick', but all this really did was move the problem, which is made clear when you have a platform object stand on another platform object.

    >

    > There are ways that this could be changed so that you don't have to think about the tick order of behaviors, but I wouldn't expect to see them in Construct 2, what with Construct 3 being the primary development focus now.

    >

    C2 doesn't export objects in folders, it's all in xml files, where they're stored in the order they've been created, regardless of the "folder" they're tracked in through the IDE.

    Dude, I know that. I regularly edit the xml myself when I want to change something in a way that the editor won't allow (like moving a member variable between an object and a family).

    To clarify on what Construct 2 does on export, it goes through the xml tree and assigns ID values to the object definitions. Presumably, it assigns them sequentially in the order that it finds them, and this order can be changed by moving objects into subfolders (<object-folder> elements in the xml). These ID numbers are how construct 2 refers to object definitions at runtime, and they can affect the order that behaviors are ticked.

    This is also why you can't create objects by name, as the names you assign in the editor don't exist anymore at runtime.

  • It's almost impossible to do anything about bugs that I can't reproduce. Step 1 is to reproduce the problem, so I'm still stuck on step 1.

    I'm with you on that, but the usual methods of achieving that step don't seem to be working. Perhaps we need to think outside the box.

    I'll try to keep this little story brief. Back in the days of Windows XP, there was a crash bug that afflicted

    many users in every game, and for a significant period of time, no developer knew why. EA would just tell you that "you didn't meet the minimum requirements", even though their own utility said the opposite. Then, Valve stepped up and said, "ok, someone send us a computer that can reproduce the crash". Someone did, and then Valve found the cause. Users were running out of paged pool memory, as windows wasn't allocating enough for some arbitrary reason. The problem was worked around with a registry tweak that forced windows to allocate more, and the problem was fixed for good in Windows Vista.

    That being said, I don't think the cause of this Construct 2 bug is so obscure as to require shipping a computer to you. So, lets try some other options first.

    I am able to reproduce the bug in a virtual machine, so perhaps I can let you remote in to it, and you can do as you will with it?

    I could probably reproduce it on a virtual machine provided by you. I have yet to find a computer that I can't reproduce this on.

    Perhaps I could send you a virtual machine with a save state?

    If you have better suggestions, I'm all ears.

  • I tried to do some more digging into this, and found something I thought was interesting. Construct 2 appears to have some utility used on it to provide anti-debugging features. This begs the question: When Ashley tested wertandrew 's capx, did he use the same executable that is distributed on the website, or did he use a version of it before the anti-debugging utility was applied? I ask because a bug that only shows up in the 64bit version could easily be the result of this anti-debugging utility doing something wrong.

    Ashley, could you at the very least respond to let me know that you have read anything in this thread beyond the first page? I'm getting the feeling that you haven't checked back on this thread since last year.

  • *quote snip*

    I didn't mean "behaviors" in the sense of C2 Behaviors. I meant functionality (through events) shouldn't be affected by what folder something is in. Poor word choice on my part.

    The events are only being indirectly affected. The functionality change isn't related to the events at all. You get different results because the behaviors (both platforms and the sine) evaluate in a different order. This causes the positions of the objects to be different than they otherwise would when the event sheet is evaluated, which then changes the result of the conditions. You can see this when the player 'lags' behind the other sprites. The platform behavior attempted to solve this problem by doing its move logic in 'posttick' while other behaviors use 'tick', but all this really did was move the problem, which is made clear when you have a platform object stand on another platform object.

    There are ways that this could be changed so that you don't have to think about the tick order of behaviors, but I wouldn't expect to see them in Construct 2, what with Construct 3 being the primary development focus now.

  • > Changing the folder it's in seems to change the tick order of the behaviors. This is probably related to how Construct 2 assigns IDs to objects on export. If I put Sprite in 'Folder1', Sprite2 in 'Folder2', and Player in 'Folder3', IsOnFloor is constantly true. If I swap Sprite and Player, then the described buggy behavior occurs.

    >

    Yikes. That is no good. Load order shouldn't affect behaviors like that.

    Ashley, have you had a chance to look at this yet?

    The behaviors need to be updated in some arbitrary order. Construct 2 tries to hide some of this from users, but since it can't automatically figure out what your intended behavior is, you will inevitably have to deal with it at some point. At least like this, you have some level of control over it.

    This is why I prefer to use events whenever I can, since I have complete control over the order those run in. Behaviors could have this same level of control too, IF they provided the option of disabling their javascript tick functions and using an action to trigger them instead.

  • Well, it's hard to tell what is going on without a capx, but I would suggest making sure that the project ID (the com.mycompany.myapp thing) is different between the two applications. Also, open up the .caproj file in each and make sure they have different <unique-id> elements.

  • Changing the folder it's in seems to change the tick order of the behaviors. This is probably related to how Construct 2 assigns IDs to objects on export. If I put Sprite in 'Folder1', Sprite2 in 'Folder2', and Player in 'Folder3', IsOnFloor is constantly true. If I swap Sprite and Player, then the described buggy behavior occurs.

  • I decided to poke at this bug again today. As we know, scrolling around in the affected projects changes how they render significantly. So, I decided to put GLIntercept to the task, and find out what happens differently between good renders and bad renders.

    In both my example and in wertandrew 's example, the objects that disappear are being rendered to framebuffer 1 instead of framebuffer 0 like everything else. It even sets up new projection and modelview matrices for this framebuffer. Framebuffer 1 is also never cleared, which leads me to believe that the usage of this framebuffer was completely unintentional in these cases. I imagine that this extra framebuffer is meant to be used to render layers that "force own texture", but is being erroneously triggered in these examples, and only on the 64-bit version of the editor.

    Ashley, I've uploaded these captures so that you can review them. Open the IEViewLog.hta file in each folder to view the capture.

    https://drive.google.com/open?id=0B40Xy ... EY4aHJwSVk

    Each capture shows the full framebuffer before and after each render call, as well as a diff image.

  • Well, you can get the image data from the blob URL by using the AJAX plugin, but restoring that back into a sprite isn't something I have a solution for off the top of my head.

  • Johncw87

    Thanks for your tip John. I don't want to make you work but could you do a quick little example of 139 vs 239 and show improved performance? That would be a huge help and shed light on this for all of us! <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">))

    Thank you man. <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

    Ok, but only because I was planning on re-installing Construct 2 to test something else anyway.

    I took the project you posted, and made the modifications I mentioned. Window size is 500x500, and the layout scale is set to 0.05. I also modified the project XML so that Construct 2 rev 139 would open it. Visually, it's exactly the same.

    https://dl.dropboxusercontent.com/u/207 ... 20fps.capx

    In version 139, I get 22 - 27 fps, with an occasional dip

    In version 242, I get above 50 fps, with an occasional dip.

    These tests were run in Firefox 50 32-bit