Colludium's Forum Posts

  • As long as we get the option of being able to choose which version of NW we can export to then all will be well. Lunatrap, when I try my game in the new version of NW (and chrome 39 for that matter) it's like I took a step back in time and am trying to run my game on a microbook or some other completely inadequate hardware. There is a hacky fix (edit - fix is a bit strong, it's a work around) involving replacing the package.nw, but I suspect that Ashley will have sorted this out before long.

    Edit - actually Chrome Canary is worse than the old NW. By a country mile....

  • asm.js is limited to 8 collision polygon points - many of those sprites have more than that... I seem to recall that concave shapes are also not supported by asm.js, but I'm struggling to find a reference and might be mistaken.

  • Same here. I know that we rely on the support of 3rd party wrappers for the majority of C2 exports, so it would be helpful if we could select which version of node we want to use for instances just like this - where the 3rd party has made a mistake with its latest product (newer =/= better).

  • Do you have any objects with the Scroll To behavior in the layout? If not, i suspect that the scroll.x and scroll.y are set to the default 0,0 - which is causing the effect you see.

  • I think he is talking of the persist behavior, where the state of the objects with it are saved constantly, which is a great tool but lacks indeed this essential reset feature IIRC.

    Ahhh - that makes more sense. And is why I personally don't use the persist behavior...

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • To make the menu / options easier to manage, I draw those now in a global layer so they can be exposed at any time in the game. That way you only need to set the game timescale to zero before showing the options layer. Easier than saving the player and enemies game data and then reloading it all on return to the layout.

  • Do you mean global objects that you're using to hold game information in object variables? On start you can save their states as json, into global variables or an array / dictionary / web storage. Then, to reset, just load the original states back in...

    Edit to add: So you could use an array to save the player data at the start of each layout, giving you more control over how you reset things.

  • I liked the background example, very neat.

    Edit to add: The creation and distruction of the same object type during runtime sometimes caused variations in dt so it would misalign with vsync, causing occasional frame drops or partial draws. My point about recycling is that, unless you are memory constrained (mobile, & like your example shinkan) there is something to be said for holding reusable game objects like bullets in stasis outside the layout, and only bring them into play at the appropriate time. I agree that this has no bearing on single use objects and I didn't mean to confuse matters.

  • Edit: Bump x 1 (and final)

    The Button object and the Mouse objects don't play nicely together. It is not possible to detect when a mouse pointer is over a button object without using other objects to do the detecting. Would it be possible to add triggers like OnMouseDown and OnMouseOver so that it is easier to create feedback effects (by using css)?

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

    Old post below:

    I just put together this css your buttons tutorial and in the process learned that it is not possible to detect when the left mouse button is pressed with the mouse pointer over a button. The button on clicked trigger only actions on mouse button release and there is no way of detecting the action using the mouse object. This means that any visual feedback for a mouse click can only be given when the user has finished their input - it looks a bit odd if you hold the mouse button down for 1/2 sec first, for example.

    Please could we add a condition to the button object for 'onmousedown' so that we can better control our button effects? Thanks.

    Edit: kudos AllanR for discovering the expression.

  • It's worth remembering some of the tests from the jerkiness thread (I think) which demonstrate that there are overheads associated with creating objects in addition to the video memory used. The conclusion there was reusing sprites was far more efficient than creating and destroying them.

  • Heska, no worries. Due to how the browser will scale the image you will probably find that most draws of the scaled-up sprite will not be identical to the smaller version just because a different number of pixels will be used - the larger draw will have more detail. However you won't see any blurring artifacts on a scaled-up sprite in this case. So, you couldn't use this technique for a pixel art game but for other styles you could. Hope that's clear?

  • It depends somewhat on your intended market. Do you mean PC browser based or nw desktop based? If you're aiming to greenlight then this steam survey will be of interest (the primary monitor resolution will drop down to a list).

    I understand some other big games, like Airscape, are targeted at 1366x768; the one I'm working on uses that as well with an option to scale up to full screen (where possible, sprites are down-scaled for 1366 resolution so that an upscale doesn't create fuzziness). The article above is a good read as well, and you're rightly planning it out before starting.

    Performance is another thing to consider. If you go for full HD then you will have to be careful to avoid problems on low end hardware. The most common graphics processor on that list has 1024Mb vram. Good but not great....

  • I also get the same type of result if using a different color in the sprite - Firefox and Chrome are almost identical, IE is not....

  • Yeah, TiAm, I see the same as you as well (lesson: don't run tests late at night...).

  • Construct Classic used to be able to run embedded Python scripts, I think you're confusing the two progs...