marcinkowski

Destroying it removes it completely, setting it invisible just means you can't see it.

Unless you're disabling all behaviours relating to that object when you set it invisible, you could end up with an active invisible enemy, and even if you are you could still end up seeing odd things happen.

Is there any reason why you don't want to destroy the object?

—

I've not tried it in nw.js, but this should work:

Add Sprite (for button), Mouse and Browser

On mouse click on Sprite -> Browser:Close

marcinkowski

Personally, I wouldn't even bother with the Killed > 0 check, I'd just reset the variable to 0 regardless.

Of the two, though, the first one is better if you are going to add other subevents On start of layout, otherwise there is no real difference and is not something you should be wasting time on when there are so many other more productive things you could be doing to make your game better.

See: https://www.scirra.com/blog/83/optimisa ... -your-time

I have a large map in my game and I have separated it in 14 parts, which I made them all 900x1145 big by mistake. That froze my phone and I have reduced it to 450x573. But the game's performance is still not ideal and I think additional reducing of the image sizes would screw the quality of the map for better displays...

Should I consider dividing my map image into another 14 parts (28 in total) ?

What is the minimum size of an image that will look nicely on every display without causing the game to lag?

Phones often need to process images as power of 2 sizes (2048, 1024, 512, 256, 128, 64, 32), so it will upsize to the next power of 2 filling in the rest of the image with blank space.

This means your 900x1145 will be treated as 2048x2048 which takes 16MB and your 450x573 will be treated as 1024x1024 which takes 4MB.

If you can, break the large map image up into pieces no bigger than 512x512 (which only takes 1MB each), although 1024x1024 may work just as well depending on layout dimensions. For example, if the layout height is 2048, then two 1024x1024 images would work just as well, if not better than 4 512x512 images, but if the layout height is 1536, then 3 512x512 images would work better then two 1024x1024 images.

keeperdarkk

I made a basic jetpack/flying example for someone else a while ago that might be useful to you.

example capx

You can change the key used for flying to be the same one used for jumping in the events - currently uses SPACE for flying and default platformer controls for jumping.

LaurenceBedford

Use a SpriteFont for the number which you spawn when you destroy the Coin, give it two Sine behaviours, one for Size and one for Height, and the Fade behaviour.

Set the Fade time to a quarter of the Sine period (so it only increases and moves up), e.g. 2sec Fade, 8sec Sine, and destroy it when the fade finishes.

Should Scirra start planning to make Construct 4 export to smartphone platform natively.?

Does it have to be native?

Scirra are working on having a "one-click" export option to apk (Android) and ipa (iOS) for Construct 3 and have most of it in. Isn't that enough?

piranha305

You mean like calling a Function?

EamonWong

A while ago I made myself a function to shuffle a comma separated list, and it sounds like that is what you need.

Shuffle Comma String capx (r244)

The function is self-contained, you just pass it the string as a parameter and it returns it to you re-ordered, so as long as you have the Function object in your project, you should be able to copy and paste the function from the example.

Smedis2

Simplest way I can think of is to use a TiledBackground for the image and adjust it's Height over time

capx (r244)

Once fully loaded you can replace it with a Sprite, if that's what you need. I've just set it to loop for the example.

Note: I use negative values for the Height to render from bottom to top

InfiniteRockets

You could try setting the origin point of your platform sprites to the bottom left and just spawn at LayoutHeight, that way the height of the sprite doesn't matter.

I'm not a fan of subscription models in general myself and argued against it in other threads, but Scirra are too far into things to change from the subscription model to a buy once model at this point, and they have some understandable reasons for wanting a more stable income which should also benefit the users of Construct 3.

The Scirra team have heard all the arguments against subscriptions and have at least given consideration to some of the suggestions to make the subscription model more palatable.

Tom has already stated elsewhere that they are considering and discussing internally the suggestions of monthly subscriptions or pausing subscriptions, but that they might not come into affect until after the first year.

Ashley has also stated elsewhere that they are looking at the possibility of allowing people with lapsed subscriptions to modify and re-export previously exported projects - basically allowing users to maintain their apps without requiring re-subscription.

Now it's a matter of waiting to see how things work out, or if you can't do that then moving on to other software.

On a side note, I also think the Scirra staff have been quite lenient in how long they left the other threads open given some of the harsh comments and personal attacks in them.