Prominent's Forum Posts

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

    someone else, with a subscription .. could fix that bug for a small fee prospects I tell ya.

    I hadn't considered that prospect. Seems like a good method of covering the cost of subscribing.

    >

    > Subscription will never give anyone the luxury of owning something. .

    >

    How about the games actually made with it ?

    Let's say someone owns a game they developed but can't work on it any further due to lockout. A player discovers a game breaking bug that they'd like fixed- it can't be done because the game's developer needs to get permission from Scirra first. Access to a potential fix is held at ransom in this case because there is no other alternative to fixing it.

    In this scenario Scirra has a stake in your development, and can dictate how that development is handled or how you handle the games you've made.

    It's kind of like being sold an instrument that is out of tune and the only solution is to tune it, however, only Scirra knows how and you have to pay them to get it tuned and there's no guarantee it'll be tuned perfectly. Overtime it might go out of tune again, it might break, parts might need replacing. If you look at it this way, then you realize that what you are buying into is a faulty product that you have no control over at the end of the day. Yes, buying into it allows you to use it for your own benefit/enjoyment and play music, and you can earn some money by playing the music for other people. The music belongs to you, but you never own the instrument- the only instrument of its kind that can play that music that belongs to you. You can duplicate that instrument and give it to everyone on the planet, but nobody can fix it until Scirra permits it to be.

    Now you can even take the argument further if you consider 3rd parties that Scirra relies on. Even if Scirra deems that you can develop the instrument further after paying up, they might provide you with tools that are faulty or unreliable. So not only do you have to appease the gatekeeper, you have to rely on other entities behind that gate that might change at any time.

    Sure, this is an exaggerated example. It's not as serious as this example makes it sound. I like Construct, and I want to see it improve- and it probably will. However, a lot of things won't improve or change, let's be honest. Does that make Scirra bad or make Construct anything less than it is? No.

    I think what people here are doing is just figuring out what is right for themselves. Do they see themselves using a specific instrument, does it make the kind of music they like- how can they express it now and in the future, etc..

  • The remove from sale button does not show because the items are in bundles that have been created by someone else back in 2014. Those bundles are still active and until they become inactive I can't remove those items from sale.

    I will send an email.