Ashley's Forum Posts

  • Honestly, I have doubts this is at all helpful. I'm sorry, it's a very complex engine and it has years of subtleties coded in for long-ago bug fixes, backwards-compatibility purposes, and optimising for general-purpose performance rather than specific cases.

    For the leftover semicolons: this basically doesn't matter, but the reason it's there is because the exporter deletes all assert checks on export. It has to leave a semicolon so they still count as statements though. For example:

    if (x)
    assert(y);

doSomething()[/code:1uagwfj6]

If the runtime deletes the assert [i]and[/i] the semicolon, this effectively becomes:

[code:1uagwfj6]if (x)
    doSomething();[/code:1uagwfj6]

What was previously an unconditional call is now conditional based on the if. So in this case your suggestion of removing the semicolons could create bugs where there were none before.

"nextHighestPowerOfTwo" has never come up in any profiling measurements I've made so I believe any attempts to optimise it are just a waste of time.

The collision checks are optimised for general-purpose performance. It's often possible to take some specific case and optimise that to be something like twice as fast, but it could make other cases half as fast. That's not a good tradeoff for an engine like Construct 2, since making some games slower and others faster is worse than having them all run at reasonable performance. (What if your game is one of the slowed-down ones? "It made other people's games faster" isn't much consolation.) For example the existing C2 segment intersection check can early-reject based on a bounding box check before it does any math. Your alternate version does some math calculations before it can reject, which isn't necessarily faster or slower over all, probably just different (a different set of cases will be faster/slower). The same is probably true of your contains_pt code.

Then on top of that, there is a significant backwards-compatibility concern. One of the reasons I don't want to make any changes to these functions is they are absolutely core functions that almost every game heavily depends on. In the early days we made some tweak - smaller than your changes - and it broke a bunch of platform games because floating-point numbers started rounding in a different direction and ultimately it meant you couldn't fit in tunnels you could previously fit in to! At the time I reverted the change and it's been left like that ever since. So it seems very unlikely we could ship any such changes without breaking a wide range of games. I mean, you say yourself, your changes already broke your own game  It doesn't matter if it's 100x faster, if it doesn't work correctly we can't use it, it will break existing games, and if that is our overall philosophy, we end up building a buggy nightmare of a product which is fast but never works properly (quite a good description of how Construct Classic ended up).

Finally, I'm afraid if you so much as change a single line of code in the C2 engine, we can't support you any more. For example we cannot accept any of your bug reports any more. If you have even a tiny change to the engine, and you report a bug, we will reject it in order to rule out the chance the bug is caused by your own engine changes (which is especially likely if it's an unfamiliar codebase). A warning to other users: this is also true if you are looking at these posts and decide to paste in any changes to the engine. If the code is not 100% exactly identical to what comes with the installer, we can no longer offer support.

I don't see that you will be able to overcome any of these limitations in your approach, so I must discourage you from trying this. By all means hack away and experiment for your own learning purposes, but we will probably not use any of the changes, and we cannot offer any support if you have made a single change to the engine.

  • Haha kinda funny to see such an old thread. Yeah, so I got the angle expression wrong in 2008. I do apologise. Hopefully I got it right for the last eight years instead XD

  • Yeah, I guess that would do it. We're just so pushed for time right now I don't think we could prioritise anything that isn't essential, though.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • There would be a lot of tiresome admin work whitelisting people's suggested URLs, plus there would be grey-areas that are difficult to define e.g. a facebook page that looks like a possible scam, etc.

  • I checked the engine code and we block navigating away and opening popups as well. IIRC we were concerned about people submitting games that redirect to malicious sites or spawn popup ads. That would still be a concern if we were to enable this again.

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

  • These days 170mb isn't that bad. A lot of devices have 1gb+ memory now.

  • If you have trouble using the Intel XDK, you should report it to Intel, since it's their software.

  • Please test r228 as per the bug report guidelines, particularly since we made a relevant change in that release. Also as per the bug report guidelines we require a .capx to be provided, and the guidelines describe why it's our mutual interest for you to not send your full project.

  • Please file bugs for other platforms if you have trouble with them instead of using deprecated platforms. We cannot offer any support for Canvas+ any more.

  • This sort of came up in another thread recently. It wasn't quite the same thing since it was to do with scrolling, but it's kind of related. Basically if you use letterbox integer scale, point sampling, low-quality fullscreen mode etc. for pixellated display, then scroll to an object moving at something like 40 pixels per second, you get an irregular scroll pattern. 40 doesn't divide neatly in to 60 (the most common display refresh rate) so you get an irregular on - off - off - on - off - on - off style pattern which looks bad (the human eye much prefers regular updates). And the cause of that is maths, not any particular aspect of Construct 2. Then it gets more complicated when you consider different display rates: it will look OK on a 120Hz gaming display, because 40 divides in to 120 (exactly one pixel every three frames).

    One of the issues is pixel rounding rounds the display position but not the actual stored position, which is also why you can get uneven stair-step movements as the X and Y axes update at different times. You can probably resolve that just by making sure the object starts on the same pixel offset on both axes. Then you have to avoid features that adjust the position smoothly as well. Then you also lose the benefits of framerate-independent games: it could well run at double-speed on a 120Hz gaming display.

    Construct 2 is a modern game engine so everything is done by floats with delta-time, which is often useful for smooth, accurate and consistent movement. However older games on much more primitive hardware would have manually adjusted positions as integers on a tick-by-tick basis. You can also do that with events, but it means not using the built-in behaviors. Also I am fairly sure modern displays make this more apparent than it was in the heydey of older consoles - something like the NES would have been running at a tiny 256 x 240, likely on a small CRT display, which were often slightly fuzzy making pixel boundaries less obvious. Run the same game on a 1080p display with perfectly crisp pixels, making each pixel a large clear crisp square, and suddenly you notice things you might not have noticed before.

  • Canvas+ has not been supported for over a year. Either contact Ludei and ask them to fix it, or (as we strongly recommend) use one of the webview based platforms.

  • I would recommend making a bug report to the Bugs forum with a public .capx file. The guidelines describe why that is more useful and how sharing a private .capx usually makes fixing the bug more difficult.

  • If you think Construct 2 is exporting the project incorrectly, please file a bug report in the Bugs forum following all the guidelines. If you don't do that, there's nothing we can do to help.

    If you think the Intel XDK is building your project incorrectly, please contact Intel for support.

  • Please file a bug report following all the guidelines or the problem will not be investigated. Note this thread was originally from 2013, it could well be a completely different issue.