okay, yea- better to work on stuff that will actually improve the product.

For a lot of these games I'm getting several of the same errors in the console:

Uncaught (in promise) DOMException: Unable to decode audio data

Uncaught (in promise) DOMException: Unable to decode audio data

Uncaught (in promise) DOMException: Unable to decode audio data

Uncaught (in promise) DOMException: Unable to decode audio data

This causes the loading process to get stuck.

edit: seems to be related to this: https://github.com/Scirra/Construct-3-bugs/issues/358

narFsnw's and mikesnorth's games get stuck loading for me.

damjancd , is the broccoli the only draggable vegetable? Can't click-drag the other two, they also don't get stuck to the broccoli unless i keep hitting them together fast.

cangelodawg , I found the 3 castles- looks like a good start. maybe some thing moving that you have to dodge would add to the fun.

Because of what I explained in my earlier reply.

Yes, but you added particles as an alternative to using sprites, and for those you don't use the collision overhead. Seems like you discarded that because it wasn't needed- so if a person has a case for not using collisions with sprites, then you say "well there would be no significant benefits from that method."

There are plenty of cases where a person can't use the particles because of the limited control over them, and have to resort to using sprites. It seems like the particles system is exactly something you shouldn't have created in the first place if you don't want to create multiple types of object for construct that are similar to each other.

So why not just modify the sprite object to be more customize-able and get rid of the particles? replace it with a plugin.

I know you can't do that though because you want to keep compatibility- I'm just saying..

Maybe I just don't understand this though, so if that's the case just ignore me.

> but then why does Construct particles use that method?

>

Because particles are an obvious and easy isolated case in the engine where you might actually create several hundred of the same "sprite" (although the individual particles are not really sprites).

So if I need to make several hundred of the same sprite (not particles), are you saying there is no benefit of having the collision stuff removed in this case? Why is it beneficial for the particles case and not the case I describe?

Ashley , you say this; "I honestly doubt many real-world games would be meaningfully faster with the particles rendering method."

but then why does Construct particles use that method? You must have seen some benefit of adding that in the past. So why all of a sudden say that it wouldn't be helpful in any real-world games?

I'm a bit confused.

tunepunk , I guess it would depend on your workflow and how you're designing your maps, and the interactions with the map. In my case, I was designing a game that had the map procedural generated, so the terrain would always be different when the game was run. It would create the terrain in various tilemaps, and then I would paste those using the paster plugin, and remove the tilemaps afterwards.

For some reason the tilemap becomes very inefficient when you want to actually make an interesting map that has a lot of variation, and also use multiple tilemap layers. Actually the reason isn't a mystery- it actually is due to it having to change draw calls whenever the tile changes to a different type of tile.

So if you need a way to make adjustments to the map in the editor or maybe need to refer to the tiles or objects in order to setup other objects at the start, etc, then this becomes more useful.

How exactly did you go about this? I couldn't find any actions for resizing the viewport. Only scaling for layer and layout. I'm curious to try a similar approach, to see if there's any performance benefits.

I believe it is Set Canvas Size, under the browser object. The first action in that object.

Another way you can do it, although it might be slower, is to pan across the layout and paste as you go- so you could find how many times the width of the viewport fits into the layoutwidth and reposition that many times pasting each time.. etc..

But I think it is quicker to resize the viewport since it requires less pasting.. The difficulty is hiding the view as you do that.

You might have to limit the resized viewport anyways if your layout is super huge, and reposition like a few times to cover everything (there is a max texture size of the paste/canvas?) idk.. I remember having some issue with super large layouts, and using a viewport of like 25% the size of the layout helped.

edit: btw, if you use multiple tilemaps that have reasonable complexity to them, you will get a huge speed increase by flattening it this way. Of course you lose the layering of all the tilemaps, but you could still have a few pasted layers and sort it all out. Definitely improves speed if you're using a lot of tiles.

But a very important note here is that even though optimization is important, the code architecture and readability is even more important.

I can vouch for that. After all my time using construct, that is what I have found to be the most important. I can probably safely say that because construct allows fast development, it probably is the reason why I learnt this lesson. You can create stuff pretty quickly in construct, but if your code architecture is bad, if it is unorganized, unreadable- you'll have difficulty scaling your projects as you spend more time on them. It's pretty crazy. Like not seeing the forest for the trees.

There are numerous times when I use sprites, yet have no need for their collisions. Particles are too limited because they can't be controlled in the same way. It would be nice to have ability to remove that collision overhead from the specified sprites.

So, almost a week later after emailing, they managed to remove one bundle, allowing me to remove one of my items from sale. They somehow couldn't understand that I needed two bundles removed. So I am still waiting for the second bundle to be removed. They also thought that the bundles were created by me, which they weren't- wanted me to remove the bundles myself.

edit: it is now solved.

I haven't added too much, but I do have ability to set margins/edge style/fill style of 9 patches. Setting the frame duration of a sprite animation.

I can also retrieve those values.

I can also retrieve the imagepoint name if I give the animation/frame/point index.

I can also retrieve the image point index if I give the animation/frame/point name.

whenever I need some capability like those I just add it to this behavior.