Graphics in Motion - What Comes with the Territory?

Anything beyond the basics in using the LiveCode language. Share your handlers, functions and magic here.

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

Post Reply
Gage
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 224
Joined: Tue Mar 26, 2013 8:59 pm

Graphics in Motion - What Comes with the Territory?

Post by Gage » Wed Aug 31, 2016 2:38 pm

Hello all,

I have been an LC developer since the original Kickstarter project, and before then was not a developer at all. Therefore, LiveCode is the only programming language I have notable familiarity with (exceptions are one term of C from university and some Matlab, Visual Basic for labs in university).

At this point in my life, I am working on deciding whether I want to carry on with development; it's a potentially lucrative career, offers the option to work remotely and independently, and there are many creative/entrepreneurial possibilities.

However, I am sometimes uncertain about the general stability of LiveCode as the answer to my needs, and am contemplating taking another direction entirely. However, with no real basis for comparison, I don't know if the discouragement I often feel is inherent to development or if it's kinks that are still being worked out as LiveCode is locked down.


Specifically, here are my questions:


1) Are smooth graphic movements a realistic expectation in LC?

Contextual Clarification:
I want to make some game-like UX to spruce up apps and market them on the app store to supplement my income. However, I notice that the object movement scripts I write, which work exactly as I want in the IDE, are unacceptably rough and glitchy when deployed on my (less than one year old) Android mobile device.

I suspect this is because LiveCode's engine is operating separate from the device's OS/processor, and that LiveCode only gets to update the device screen on a low frequency, causing the glitchy movements that irritate my eyes and crush my soul. I have absolutely no education/background/experience on understand processors and how that stuff all works; I got on board with LiveCode in the hopes that those considerations were worked out by the experts behind the product, as I have meager passion for discovering and decoding such mysteries myself.

Am I S.O.L. or is there some way to make a deployed LC app's graphic movements run as smoothly as any game app's on the App Store?


2) Should I expect to make a lifetime effort of juggling software versions?

Contextual Clarification:
Having put a completed app on the iTunes Store and the Google Play Store, I have noticed multiple times that there are combination lock-style upgrade efforts that need to be made to keep the app working as it used to. I originally uploaded a debugged (passably so, anyway) app that functioned as intended.

As new OpenSSL versions (for example) come out, Google alerts me that the software needs to be upgraded. This, of course, means I have to re-license (if expired), get the newest version of LiveCode (assuming it has included in it the upgraded versions or whatever that Google is calling for (this is more stuff I don't really understand, to be honest...), and then find the exact perfect combination of various other integrated technology versions. In the process, features that have changed stop functioning, and suddenly the app isn't working at all any more.

To me, this is mind-numbing, painful, boring, and it seems like the forward progress of the various technologies (which my app did not need, to my knowledge) has forced me to do a lot more work just to maintain what I already had completed. Is this normal in development never to find your app's "sweet spot" or to be able to leave a functioning app alone? Am I messing something up or not taking enough precautions? Seems like companies' progressions are equivalent to pulling the rug out from under the feet of developers with already-completed projects.


Please help me remove my illusions and understand the reality. If my expectations are not realistic without immense amounts of understanding of the back-end functioning of software and hardware (which I had hoped to skip over by teaming up with LC), and if it's laughably noobish of me to think I could "finish" a project and trust that it will stay "finished", I'd like to be able to make informed decisions on how to proceed instead of wandering delusionally from frustration to frustration.


Thank you very much, you have no idea how helpful red-pill (blunt, real truth) responses will be for me in these matters.
Phil E.

P.S. My intention has not been to offend anyone who knows more than me about any of the things I'm bringing up. I'm just trying to learn what things come with the territory, and if these things are not inherent, how I can adapt and improve my programming practices to be able to achieve what I'm intending without instead meeting frustrating and disappointing results where I see no room for improvement on my end.

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7389
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

Re: Graphics in Motion - What Comes with the Territory?

Post by jacque » Wed Aug 31, 2016 7:09 pm

1) Are smooth graphic movements a realistic expectation in LC?
Yes, but you need to set the layerMode of the highest level control to "dynamic" and the acceleratedRendering of the stack to true. See the dictionary about these properties, and I believe there are some LC lessons too.
2) Should I expect to make a lifetime effort of juggling software versions?
Probably, it's normal for development in any language. If the OS changes the rules, everyone has to update their code for compatibility. LC has a slight disadvantage here because we need to wait for the LC team to update their code before we can update ours. However, they are very responsive about this and it would be rare to have to wait very long. When QT was discontinued, they dropped everything to produce a compatible Windows release, for example. (The Mac version had already been updated.)
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

Gage
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 224
Joined: Tue Mar 26, 2013 8:59 pm

Re: Graphics in Motion - What Comes with the Territory?

Post by Gage » Wed Aug 31, 2016 7:20 pm

Jacque,


Thanks for the responses!

So, for 1), is this "highest level control" the control with the highest numbered Layer? I'll look into it.

And for 2), I kind of expected as much, unfortunately... I'm kind of realizing my dream of creating an app and setting it free into the world is a pipe dream. It's more like having a baby or a pet. I've seen that the version updates are basically always on time from LC (thanks, team!), but I had a fantasy of being able to produce something self-sufficient that could be developed once, tested, and released to fare as it may. To check for understanding, it wouldn't be likely to be able to produce a simple Tic-Tac-Toe game or something that needs no complex integrations or security on, say, a very old version of LiveCode, and just let it sit without upgrading and expect it to work? I guess it goes back to the OS of the devices running it. If they deprecate the protocols that the LC version was dependent on, a new version would be required to keep up with the times. Castle built on shifting sands.

Thanks again,

Phil E.

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7389
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

Re: Graphics in Motion - What Comes with the Territory?

Post by jacque » Wed Aug 31, 2016 7:52 pm

So, for 1), is this "highest level control" the control with the highest numbered Layer? I'll look into it.
It's the highest level (highest layer) of the control that needs to move. If you are moving only a single object, like a button, then that's what needs to be dynamic. If it's a group, then set the property on the group. What "dynamic" does is control what goes into a buffer in RAM so that screen redraws are fast, because only the area that moves is redrawn. The rest of the window can remain untouched. This is way faster than redrawing the whole window every few milliseconds. Think of it like cel animation, where the background remains static and only the frontmost layer needs to change.
I'm kind of realizing my dream of creating an app and setting it free into the world is a pipe dream.
Not necessarily, it depends on what your app does. I have a pretty old app all the stores, the App Store, Play Store, and Amazon store, and it still runs fine after 3 years. The app depends only on LC scripts and doesn't use any externals or system components, so it will continue to work fine until/unless one of the operating systems stops allowing backward compatibility. If your app uses features that the OS stops working with, then yeah, you're in for a rewrite. I'd doubt a basic tic-tac-toe game would need any changes for a long, long time.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

Gage
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 224
Joined: Tue Mar 26, 2013 8:59 pm

Re: Graphics in Motion - What Comes with the Territory?

Post by Gage » Wed Aug 31, 2016 7:55 pm

Jacque,


You nailed it! Cool, well I will keep those things in mind as I make my way. Thank you very much for taking the time to help me out.

Best wishes,

Phil E.

Post Reply