Arrays Don't like Negative Numbers

  • @Murtaza said in Arrays Don't like Negative Numbers:

    As I said undo was a choice we made on purpose and not something we overlooked. But I really appreciate you thinking we're incompetent.
    We're always looking to hire additional programmers, so if you ever go beyond hyperPad and get an engineering/computer science degree maybe you can come and add undo .

    Keep swinging. You're still hitting air.

  • @Murtaza said in Arrays Don't like Negative Numbers:

    But I really appreciate you thinking we're incompetent.

    I'm not sure I'd use the word "incompetent". I don't think you did enough research into the different ways UNDO can be implemented. When you discuss the memory and performance issue with regards your reasoning on it, I know you didn't look into it enough.

    Probably because you don't understood the significance of UNDO in digital creativity. Otherwise you'd have done the research on ways to economically build around the ability to undo, and probably created an undo list, too. It's still bewildering you chose this path. It troubles me that you have this little regard for your users, or this little interest in researching the capabilities and supports provided by the platform you're working on.

    Going back as far as 2010, Apple were spending an incredible amount of time demonstrating ways to implement UNDO and REDO efficiently because they'd become big believers in its significance to apps and their users' experiences. Beyond believers. I think we can consider the existence of undo to be expected in content creation and productivity apps since before you were born. Even in todo list apps.

  • Admin

    A few things.

    1. @Deeeds don't be disrespectful. I sent you a private message before about this. As you can see, everyone is just trying to help and you don't need to shoot them down and berate them. You're coming off as very aggressive and rude.

    2. At this point, our users are way better at using hyperPad than we are and in this public forum, we rely on their help to answer simple questions. Like @Murtaza said, a lot of "bugs" are just user error so it makes sense to troubleshoot the issue with others before myself or @Murtaza can come in and declare it to be a bug.

    3. Don't make assumptions about years of development when just coming into the platform. If you don't like something, let us know and we can have a public discussion of how things can work. Some things may look easy to add, but as most software developers know, NOTHING is ever that easy.

    4. Somethings are indeed broken. We don't know about all of the broken things. When dealing with software with 1000+ features, its easy to forget about certain items and miss some things. We rely on user feedback to find these issues. e.g. I constantly forget about some of the behaviours you guys ask about... because we have so much functionality!

    5. Everyone uses hyperPad differently, so we have to cater to how the majority uses hyperPad and not just you. appreciate our limitations and understand that we can't always cater to an individuals needs.

    In conclusion, relax. We're working on it.

    P.S, I can't re-create your issue... so I declare it not a bug. If you can create a little sample project with as few behaviours as possible, either I or someone on the forum can help troubleshoot it. like @Aidan-Oxley said, its not too hard to share a link onto the forum.

    P.P.S Its really hard to find your issues / feature requests with a huge wall of text. Keep it short and to the point, and you're more likely to hear a quicker response.

  • A few other things:

    When your professional tier, your highest priced premium version, crashes hard, and restarts, every single time it's loaded after the iPad sleeps (something iPads do because they're mobile devices with batteries!) and there's no indication of you acknowledging this problem or making any endeavour to properly fix it anytime soon... I think the onus of proof is on you for any and all signs of bugs and inconsistencies in performance.

    You're lagging on fixing a fundamental and massive flaw that you've done the dodgiest work around on possible, preventing your app from letting the iPad sleep.

    I am a prolific app buyer. In product categories of interest to me and my research. I buy and try prodigiously. Just in music apps, alone, I have bought just about every sequencer, DAW, effect, synth and sampler. Not one of these apps, some of which are vastly more complex than hyperPad and often made by individuals (not teams), has had the temerity to be in the market in such a crashy prone manner without addressing its users and making a fix as fast as possible.

    A real fix!

    And a lot of these apps are partly written in Assembler so they can really thrash the CPU for their DSP.

    Your "fix"? Prevent the app from letting the iPad sleep.

    For an app that doesn't idle in editor mode, that's insane! I'm amazed Apple hasn't sent you a warning about this or seen this show up in their automated testing. Perhaps you're not getting flagged because it seems like a game to their automated testing.

    We know it's not being given a lot of oversight due to a lack of users. But how's that going to change when you treat them this way?

    But, let's be honest, your app, in idle editor states, is flogging the CPU/GPU so hard that it destroys the battery life of iPad Pros!!!

    And you exploit this to avoid your users having their iPad sleep, and then crash and restart your app each time they turn back to it.

    You haven't even bothered preventing your app from flogging the CPU when in editor modes.. and IDLE!!!

    Are you guys really working on this full-time?

  • Admin

    In editor the cocos2D graphics engine is active. The entire canvas is the live game engine. Plus every action you take is being saved which are constant read/writes.
    These two things affect battery life.

  • @Murtaza You can stall the cocos2D graphics engine. It doesn't need to constantly refresh at 60fps when nothing is happening. That's one of the key design points of its actions based nature, and the same reason the early versions didn't have a traditional game loop.

  • Admin

    Oh, why didn't we think of that before! You're a genius! Thanks. You've single handedly solved all of our problems.

  • @Murtaza

    Sarcasm noted. Invert this approach to stop rendering when it's not necessary, see Brad Larson's answer:

  • Admin

    @Deeeds if you’re unhappy with our progress, ask Apple for a refund. We’re trying our best and it doesn’t seem to be good enough for you and that’s okay. We’ve been pretty attentive and patient with your arrogance and bullying but unfortunately, you’ve taken it too far and we’re putting a stop to it. Future posts where we don’t appreciate your tone will be removed.

  • @Hamed "arrogance and bullying"...

    Where's the bullying?

    Who feels bullied?


    I am prone to arrogance. Not going to contest that. But bullying is something else, entirely. Please share an example. I'm very curious.

  • @Deeeds You’re making the devs feel bullied, the way you keep judging this app and they way they run and make it. You’re the first person to ever do this (at least on the forums). It’s like you know better, even though they’ve been working on this for over 6 years.

  • @Deeeds, @Aidan-Oxley is right.
    Also, you don’t say the nicest things to some of the people that help you.

  • @Aidan-Oxley Example?

  • @Deeeds here are a few examples! Lol

  • @iTap-Development Well played, maestro!

  • @Deeeds thanks!

  • @Aidan-Oxley I used to do that. Might check my post history, some pretty bad things are probably on there. Four times as much on the old forum, I'm betting, too.

    Then I started programming. I need to invest in Raid library.

    Anyways, I understand where @Deeeds is coming from, his methods match how mine used to be, and probably still are - very defensive and willing to push back.

    That being said, no three-man team, all coders mind you, that I know could ever pull this off. Period. I'm rather surprised they made it this far, and root on any and all progress they make.

    In fact, if I ever manage to get my pea brain to understand C++ or Swift and get a (decent) Mac, I may apply (as a volunteer initially) to help them out.

    (Speaking of which @Murtaza, are you guys open to third party application development? I'm interested in trying my luck at a windows player, asset manager, screen mirror, game analytics, or anything else that may be of some help if apple and you guys are open to it, or have an API until I get a decent Mac.)

    I do have to side with the @administrators, though. I'm not quite certain how it descends to it, but the bicker and banter isn't helping anyone. The more time they spend here with fire extinguishers, the less time they can spend there with flashlights and bug zappers.

    TL;DR: When a community and team are this small, it's a LOT harder to manage and expand the people and the product, and that's before the blood moon rises.

    Sorry guys, had to have my daily dose of nosy :)

Log in to reply