oosyrag's Forum Posts

  • The on created trigger is probably running before your myEnemy sprite has any properties.

    Try a different method, such as using a container, adding the create myFont action to the event that created myEnemy in the first place. The "wait 0" trick might work here too, if you put that above the spawn action.

  • You could simply pick a random x/y, then check if the tile at my is valid and repeat. If valid, stop loop.

  • I modified it a bit to try to account for commas within cells, but I didn't really test extensively. Give it a shot and make sure to proofread.

    Note this will now completely not work for .csv files that don't encapsulate cell data in quotations.

    Edit: Also will break if you have any newline breaks in cell data.

  • You can, but you'll have to build your own sync algorithm via messages rather than use the built in sync.

  • It depends if you're booting into the layout with the large sprites.

    Blank layout (fast load, no memory use) -> Layout with sprites (takes time to load sprites into memory)

    Is equivalent to

    Blank layout with empty sprites (fast load, no memory use) -> Load images via URL into sprites into same layout (takes time to load sprites into memory)

    The top setup will normally keep images in memory when moving to the next layout with the same sprites. Have you tried making the sprites global and/or using the persist behavior after loading from URL? That could possibly keep them in memory across layout changes.

    Generally speaking, it is advisable to design around a set peak graphics memory limit rather than try to fiddle with loading and unloading graphics into memory dynamically to try to get past memory limitations (Usually results in bugs and crashes and time spent with extra coding).

  • newt No actually it's not. Try making a blank project and put 20-50 1080p images in the files folder. Notice how previews boots instantly, and there's no increase in image memory use. Now place those same images in a sprite. Boom got yourself several seconds of loading, and that memory use's pretty big. Also done tests on HTML exports, and you can clearly tell the images from files needs to be loaded from the server. They're not loaded in the same way as sprites. Also if you have a text object print the image memory use, you will see it rise considerably once you use the "load from url" action. Restarting the layout makes it disappear, and the memory use is reset.

    This is the solution to making projects scaleble. This way you don't have load your entire game just to playtest that one level giving you trouble.

    You probably didn't understand what he meant... It actually is pretty much the same. Sprites aren't loaded into memory until they are required in the layout you load into. It is the same as On start layout, all sprites load from url. The benefit is that if those same sprites are used in the next layout after that, they are not unloaded from memory.

    Try putting all your large images in a sprite on an unused layout, you will notice if you preview an empty layout, those sprites are not loaded into memory.

    You use load from url on any given layout to spread out the loading process, so it doesn't necessarily have to complete all in one tick at the start of layout. This can give your users some heads up so it doesn't look frozen in the event of large amounts of sprites loaded.

    There are also advantages such as under the hood sprite sheeting that using the sprite object gives you. Regardless of which method you use, the sprites will need to be loaded in the end and your peak memory use will be the same regardless, so you still have to split up your image memory load across layouts anyway.

    Now if there were a specific action to UNLOAD a sprite from memory in a given layout at runtime, that would open up some possibilities in certain fringe cases.

  • The advantage is that you can decide for yourself which ones to load dynamically and which ones to load normally.

    Also, there are ways to restart a layout manually, so you never have to change layouts after your initial load. You'll just have to put some work in.

  • Use play at object, or play at position actions. This feature might have limited support depending on the browser.

    You can also add an "object is on screen" condition to have it only play when the laser is visible.

  • A. Don't reset global variables to default (use local variables for those you DO want to reset).

    B. Put PlayerLives as an instance variable in an object with a Persist Behavior.

    C. Store PlayerLives in another global data object such as an Array or Dictionary.

  • I recall there was some experimentation running wrappers on a raspberry pi, and if it works on a pi I guess it should work on an Arduino running Linux.

  • For the sprites you don't want unloaded from memory, place them on the layout editor normally and don't use load image from URL. Sprites that are in use in both the preceding layout and following layout are not unloaded from memory.

  • Thanks for the info!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • What do you mean by ghosting? Looks fine to me. Unless you mean that he's grey.

    I see him falling on startup. Not from the very top, but maybe from the middle.

    No idea about the music.

    It will be easier to troubleshoot if we can see your capx.

  • Add an instance boolean variable to player to keep track of InvinciblePowerup - true or false.

    In the event where enemies destroy player on collision, add the condition Player InvinciblePowerup = false.

    Copy that event, change it to true, and change the action to destroy the enemy instead of the player.