BadMario's Forum Posts

  • If only debugger had a debugger of its own. Maybe in Construct 4

  • You could just use another condition in your damage thingy. If player not flashing ( assume that is an animation ) damage = OK.

    So as long as it is flashing it will not pick up any damage

    I think you need a nap. That is not at all what I am saying.

    Given that 95% of your customers are on Windows it makes sense to concentrate on making sure you have a stable standalone on Windows.

    After that is done do whatever you want with browsers and other OS.

    You still cover everything just as you have now, but it would be Windows version first, then the rest ( and I am sure that is what almost everybody here wanted anyway ).

    [quote:b8oaqtuf]So... because of a bug in a browser that isn't supported at all on Windows... you think we should have made a Windows app first?

    No, but one day it will be a bug by Google and it will take down all of your customers who regularly update their Chrome browsers without thinking.

    You answered after I added, basically my answer to that.

    Nothing wrong with your browser version approach, but like I said above. Stable windows version ( standalone ) first, then a browser version that would cover people using macs, etc.... makes more sense to me.

    So then do you only blame Apple when Apple break their OS, but blame us when Apple break their browser?[/code:1f78lsni]

Not at all what I said. I blame them in both cases, but you at least double your chances of things going wrong by taking the browser app approach.

    No, I would blame Apple, but relying on browsers you will have a higher failure rate. That's not even questionable. You have 2 points of possible failure. OS itself and browser code. If you don't rely on browsers then you only have OS issues. It's not rocket science.

    As for Apple, they are imbeciles who have never tested anything properly ( they only seem to test their own programs running on their own OS and even that they get wrong way too often ). Going back 10 years or so, I can recall them breaking numerous programs, mostly through quicktime; Maya, Lightwave 3D, a number of video editing and compositing programs as well. And they have done it on their own OS and Windows.

    Windows updates sometimes break things too, but it has been nowhere near the idiocy I've seen with Apple.

    As you say: [quote:1100ku2c] Apple are a multi-billion dollar corporation with thousands of engineers, and their software is broken

    Given that, HTF is it possible to release software that constantly breaks things. Bugs are one thing, but this is on a completely different level. Do they recruit their software engineers directly from special ed classrooms? Seems to be.

    So, no I blame them, not you, but if it were me, I would try to develop software with as few dependencies as possible. That I guess means standalone on Windows first, then browser versions. Wouldn't even bother with Apple version, let them use one of the browser versions.

    Well, not quite.

    This is exactly a situation that many have brought up when arguing against having Construct 3 as a browser app. You cannot control what Apple or Google or whoever else do. So maybe Apple screwed up, but Scirra screwed up when they decided to rely on Apple.

  • Well, you should probably add if SPACE not held and/or if high jump animation not playing then play normal jump animation.

    It sounds like you are triggering high jump animation and then it goes back to normal jump because all conditions for that one are met.

  • Well, anyway, I don't know what it is, but those are the variables in play

    Physics + minify on export and Galaxy S6 edge = stuttering for the first 30 seconds, then after that mostly fine.

    Uncheck minify on export, problem goes away.

    Could be something on my Galaxy phone, but the fact is it happens with every game when you use physics and minify on export. Only on that phone, no problem on iPhone, iPad or any of the PCs

  • I don't need to provide a project.

    Just make any quickie sample with physics behavior in it and test it on a Galaxy S6 edge over wi-fi, everything will be fine.

    Now actually export html5 project, minified, and play it on that same phone. It will stutter, happens 100% of the time, but after 30 seconds or so goes away and things are more or less OK with occasional stutters. Now export and uncheck minify script, no stuttering. ( I have about 7 games with physics, all do this on my Galaxy S6 )

    [quote:v69o65fy]Minifying essentially removes whitespace and renames variables to shorter names. So there is no functional difference and no technical reason why this would affect performance

    Obviously there is a difference. It may have nothing to do with Construct or Chrome. Like I said it happens only on Galaxy S6 and only with minified exports of games using physics. One of your beta builds completely broke games using physics if they were exported with minified script. How do you explain that one if there is no technical reason for minifying to affect things? You fixed it in 2 days I think.

    Shit happens.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Add an election level to your game and make Trump become the mayor of your town. Instant fun.

  • Minifying absolutely affects performance in this case. In my case only on Galaxy S6, OP is also testing it on a Samsung phone,so that is why I jumped in with my example.

    This could be an issue with something else within Galaxy phones and unrelated to Chrome. I don't know, but I know that not minifying fixes it ( in my case ).

  • On my Galaxy S6 edge the problem is physics + minify script on export.

    If you test/preview on your phone during development everything is fine, but once you export and minify script it's janky. If you export and uncheck minify works fine too

    Not sure if this is the same problem you have, but it could be.

  • I don't have Construct 3, but it sounds like background layer is hidden. Look in layers tab and click the eye icon ( I assume that's the same as in Construct 2 )

  • single sprite with each bullet type a different animation

  • you can use tiled backgrounds

    background.Y = background.Y + scrollspeed

    if background.Y > 600 then reset background.Y to starting position

    That is literally all you need, just change numbers ( Y position ) to fit your game, I put 600 as an example only. That number will have to be a multiple of your tile height so it's not visible when you switch back to starting Y

    for backgrounds farther away it would be:

    background2.Y = background2.Y + scrollspeed*0.75

    background3Y = background3.Y + scrollspeed*0.5

    or up to you how much of a speed difference you want and of course, like the top background you reset each to their starting Y position once they scroll beyond certain point