TwinBlazar's Forum Posts

  • Problem Description

    I have just upgraded from r190 to r200 and I got an audio error that will crash the game and give out stack trace complaining "Failed to set the 'volume' property on 'HTMLMediaElement': The provided double value is non-finite."

    This problem does not occur in r190. I have reverted back to r190, re-exported the project as node webkit and see that the game runs without a problem.

    Attach a Capx

    http://www.mediafire.com/download/11ucq ... ioBug.capx

    Description of Capx

    The capx slowly turns down the volume of the music, using a global variable. The formula used in set volume function is -log10( 100 / ( x / 0.9*100)) *33.2, where x is a variable. This is used in my game to turn down the music or slowly fade away a sound effect. (ex. when you walk away from a waterfall) Once the volume is all the way down, the game will output the stack trace error.

    Steps to Reproduce Bug

    Have a countdown variable that slowly decrease and use it to set volume using the formula given above. After the variable is less than a certain number, the game will crash. See the event sheet of the provided capx.

    I have been trying to reproduce this in several other ways, such as giving -infinity to set volume function, but it does not seem to crash.

    Observed Result

    I got this stack trace:

    TypeError: Failed to set the 'volume' property on 'HTMLMediaElement': The provided double value is non-finite.

    at TypeError (native)

    at C2AudioInstance.updateVolume (http://localhost:50000/Audio_plugin.js:1984:33)

    at C2AudioInstance.setVolume (http://localhost:50000/Audio_plugin.js:1960:8)

    at Acts.SetVolume (http://localhost:50000/Audio_plugin.js:3368:19)

    at Action.run_object (http://localhost:50000/eveng.js:1850:10)

    at EventBlock.run_actions_and_subevents (http://localhost:50000/eveng.js:929:38)

    at EventBlock.run (http://localhost:50000/eveng.js:886:9)

    at EventSheet.run (http://localhost:50000/eveng.js:224:7)

    at Runtime.logic (http://localhost:50000/preview.js:2361:36)

    at Runtime.tick (http://localhost:50000/preview.js:2056:8)

    Expected Result

    The game should not crash, as it does not crash in r190.

    Affected Browsers

    • Chrome: YES
    • Exported NodeWebkit: YES
    • FireFox: didn't check
    • Internet Explorer: didn't check

    Operating System and Service Pack

    Win7 64bits Service pack 1

    Construct 2 Version ID

    r200

    I see that r198 got a bug fix "Audio: setting volume did not work correctly in r197", so this implies the internal code has been changed in the function. Perhaps, you could add some sort of parameter safeguard to prevent the function to crash the game just like back in r190 ?

  • See https://www.scirra.com/manual/135/particles

    [quote:3sl366cz]

    Optimisation

    Particle effects are more efficient than creating the same effect with Sprite objects, but not by a large margin. Just like with sprites, you should be aware that creating a large number of particles can have a serious performance impact on your game, especially on mobile. Use the ParticleCount expression to monitor how many particles are being created. On desktop systems, more than a couple of hundred particles is likely to impact the framerate. On mobiles, use of the Particles object is not recommended at all since the framerate is usually already limited by the existing sprites in the game; if absolutely necessary, keep particle counts below 50 on mobile for best performance.

    To reduce particle counts, try reducing the rate or shortening the timeout. To compensate, you can try making the particle size larger so the effect does not get thinner.

  • Why would you want to do that, when we actually are trying to avoid anything being plugins that require users to install in the first place?

  • This depends on how you set your game to display. See https://www.scirra.com/tutorials/73/sup ... reen-sizes

    You could have a screen that cropped up and displayed only a part of your game or you could have the whole game scaled down to fit the screen with or without respect to aspect ratio.

    Image quality would depend on how you set C2 to render. See the text below from https://www.scirra.com/manual/66/projects

    Sampling

    Choose between linear (smooth) and point (pixellated) sampling when resizing images. Linear is recommended for modern games with hi-res graphics, and point is better suited to retro games with blocky pixel art.

    Downscaling

    Adjusts the tradeoff between rendering quality and memory use when resizing images to smaller than their original size (downscaling). The options are:

    Low quality: mipmaps are disabled (reducing memory use), but downscaled sprites may appear blocky or pixellated

    Medium quality: mipmaps are enabled. Downscaling sprites generally looks better.

    High quality: mipmaps are enabled and the spritesheet after export pads out all images to power-of-two sizes. This can significantly increase memory use, but can resolve two minor rendering issues: light fringing that can sometimes occur along the borders of downscaled objects, or a quality change in the last frame of an animation. Do not use this mode unless a rendering artefact is specifically observed and selecting this mode can be observed to resolve it: the increased memory usage can be very significant, and is not a cost that should be added for no reason. For more information see Memory usage.

    ----------

    Does this answer your question?

  • TiAm Yes I understand. Ashley will have to go through a lot and I completely understand.

    I already got a better solution in front of me, so I am not requesting for any change in C2 any more.

    A screaming soul exploded inside me when the project manager requested for a change like this. A simple change from client's perspective could involve lots of gigantic technical changes and outsiders never see the internal technical pain. I've been there done that so I do understand.

  • Then you are doing it wrong in the event sheet. Screencap your event sheet and post it here.

  • What you are asking is similar to asking McDonald how to create a better cooking tools to cook better fast food. Ask Burger King or other folks and they will all have their own gorgeous and ugly ways in doing their own thing.

    From what you have mentioned in the second paragraph, you are pretty much learning and experimenting on what you are after. Keep on doing that and you will see better ways that really tailor to your need.

  • See https://www.scirra.com/manual/108/array

    [quote:2idq719v]

    Download

    Invokes a browser download of a file containing the Array's contents in JSON format. This is intended for offline development, e.g. creating level editors.

    Load

    Load the contents of the array from a string in JSON format. This must have been retrieved from either theDownload action or the AsJSON expression. It could also be retrieved dynamically from the AJAX object.

    Does this answer your question?

  • First, I know what do you mean by Pong, but after you mentioned Monster... I started to get unsure about your Pong game...

    What is the monster doing in the Pong game? Without understanding further comtext, we can't help you validly.

  • Use System Condition to test how many enemy objects are there.

    From https://www.scirra.com/manual/124/system-conditions

    [quote:28lwcnep]

    Compare two values

    Compare any two expressions (which can either numbers or text) with each other. They can be compared as Equal, Not equal, Less, Less or equal,Greater or Greater or equal.

    Assuming EnemySprite is your enemy's sprite's name, you could refer to the Count variable of the EnemySprite.

    For example, with the above system condition, you could put EnemySprite.Count in first expression and the number 100 in the second expression. Then, compare these two expressions as "< less than".

    This means, whenever EnemySprite object is less than 100, the condition will be true. You could add your action to spawn more enemies in this condition here.

  • Then... how does it actually supposed to look like? Mind do some photoshop and post it for clarity?

  • [quote:2in4o65d] The problem is that the graphics look weird and 'warped' (darkened in certain spots but not others) at certain zoom levels when I demo this capx in my browser, including the normal 100% zoom browser view in Chrome. It's a problem that's hard to screenshot, even; when you look at the screenshot I took below, the problem may only be 'visible' at certain zoom levels of your browser.

    From my guess from the statement "the problem may only be 'visible' at certain zoom levels', I think you wanna play around with the following configuration:

    [quote:2in4o65d]Pixel rounding

    By default Construct 2 objects can be drawn at sub-pixel positions, e.g. (100.3, 200.8). If the browser is using linear filtering, this can make fine pixel art appear blurry. If Pixel rounding is set to On, Construct 2 objects round their position to a whole number before drawing, e.g. (100, 201). This prevents any blurring, and can also prevent "seams" appearing on grids of objects. Note this does not affect their actual X and Y co-ordinates, which can still be between pixels - it only affects where they are drawn on the screen.

    Fullscreen scaling

    Only has an effect when a fullscreen mode is in use (when Fullscreen in browser is not Off). High quality mode renders at the full resolution of the screen. Low quality mode first renders at the project Window Size, and then simply stretches the result to fill the screen. Low quality mode often improves performance on low-end systems and is often suitable for retro-style pixellated games with Point sampling. However text, downscaled sprites and WebGL shaders appear with better quality and detail in high quality mode.

    Sampling

    Choose between linear (smooth) and point (pixellated) sampling when resizing images. Linear is recommended for modern games with hi-res graphics, and point is better suited to retro games with blocky pixel art.

    Downscaling

    Adjusts the tradeoff between rendering quality and memory use when resizing images to smaller than their original size (downscaling). The options are:

    Low quality: mipmaps are disabled (reducing memory use), but downscaled sprites may appear blocky or pixellated

    Medium quality: mipmaps are enabled. Downscaling sprites generally looks better.

    High quality: mipmaps are enabled and the spritesheet after export pads out all images to power-of-two sizes. This can significantly increase memory use, but can resolve two minor rendering issues: light fringing that can sometimes occur along the borders of downscaled objects, or a quality change in the last frame of an animation. Do not use this mode unless a rendering artefact is specifically observed and selecting this mode can be observed to resolve it: the increased memory usage can be very significant, and is not a cost that should be added for no reason

    source: https://www.scirra.com/manual/66/projects

    Since you are doing ASCII/ANSI graphics, you may wish to turn Pixel rounding on and set Sampling to "Point".

    See if this is what you want.

  • [quote:pp78fjeq] I don't understand how you could possibly need so many thousands of individual images? What are you doing?

    Ashley, like we've said. We are doing pixel arts like this: http://probertson.tumblr.com/post/82062 ... animations

    If imported to C2, each Sprite object could contain up to a hundred of frames or so. (But with exported spritesheet image, those hundred frames should become just a huge 512 x 512 or two instead. And that is completely fine.)

    [quote:pp78fjeq] The editor could spritesheet images for preview, but that would be a big architectural change and could slow down preview.

    We have tried some experiment on loading time.

    On our project, we tried previewing and see the time it takes from hitting "preview" button to when the game finish loading and play. (If the loading percent becomes red, we just try again until it gives in)

    • Preview Chrome: 1:13 minute
    • Preview Node Webkit: 1:05 minute

    But here's the funny bit, we have tried exporting Node Webkit, (disable minify and image compression) and it took 42 seconds. In addition, when we run the exported Node Webkit, it took only 10 seconds to finish loading.

    In other words, it seems we can test our game faster than preview by exporting node webkit and run it right now. And yes, this would also avert the red percent loading error issue entirely as well.

    Could the big architectural change slow down preview? With the above result, I don't think so. In fact, in this case, I could just well go with using the faster exported node webkit instead. <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

    We have also tried Preview Firefox, and it took 27 seconds...

    I see that preview Chrome and preview Node Webkit took the longest on the first 0-20% (loading images perhaps?), but for exported Node Webkit and Firefox, the percent just "zaps" through to 100% in seconds. In fact, Firefox seems to kick the number up the fastest (only 8 seconds to 100% after the percent shows up, in fact). Does Chrome has inferior loading speed to Firefox or something?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I would like to put using and managing sprite sheets for preview just like exported projects and better sprite sheet management here.

    More info:

  • You may wish to see https://www.scirra.com/manual/146/effects

    To change color of any tile, you can apply "Adjust HSL" effect on your tile object which allows you to adjust hue, saturation and luminosity to each individual tile object.

    If you require more assistance, feel free to ask.