Software, Fitness, and Gaming – Jesse Warden

Blog

  • Flex & Flash: Refreshing Screen During Processor Intensive Operations

    I did this to help illustrate to a homey on the Flexcoders list how you update the screen during intense operations. As was suggested by multiple Macromedians, you should have a counter keep track of where you are in the data processing, and only process a set chunk amount, update the screen, and continue processing.

    You can accomplish this through a series of doLaters. They are not perfect because they don’t ensure the same method isn’t called more than once per frame unecessarely, but trying to explain to a Java developer what:

    functon onEnterFrame()
    {
    callMethod();
    delete onEnterFrame;
    }

    …does really isn’t worth it.

    Anyway, here’s a good example any Flexer or Flasher can use to see how to update your GUI with a ProgressBar for example when you have a very processor intensive loop going on in the background.

    Update GUI While Processing

  • Your Arm Is Worthless

    “We don’t take arms here, sir.”

    That’ll be the reply in 2012 from a fast-food-dispenser machine mechanic when they start inserting microchips into your wrist that contains credit/debit card information, and you go to an establishment that doesn’t accept that as a method of payment.

    “Uh… wtf? My arm works just fine thank you; I can code with it AND pay for this meal you twit!”

    I guess since I live in the boonies, Mickey-Dees-nuts assumes us country folk don’t use dem dere creh-dit kards…

    Dude, it’s the 20th century, cash & checks are so for my parents generation… and there IS a difference between a debit card and a credit card… idiots.

    I can go 2 exits further towards Atlanta, and they take debit cards there… idiots.

  • Getter & Setter Inheritance Gotcha

    I remember reading something about this a year ago on Flashcoders, but never ran into it until today. Basically, if you extend a class that has a getter and a setter on it, your sub-class can access them just fine. However, if your sub-class defines a getter or setter of the same name, it overwrites the one on the superclass.

    So, if make a new setter function that does something slightly different in the sub-class, since the sub-class can no longer call the getter, it fails.

    That blows.

  • FAME Chronicles #1: Long Classpaths & Local Var Declarations

    Was testing out MTASC yesterday morning to see how fast it would compile our project at work, which has about 98 classes. It takes roughly 30 to 46 seconds to compile the main FLA in Flash. After 20 minutes of code modifications, I managed to get just warnings (but it’ll still compile).

    It takes under 2 seconds.

    The warnings kind of suck because basically, some of my classes had to have their symbolName properties be the same to work. Why? It sounds to me, after talking to Darron about it, like Flash’s internal Object.registerClass doesn’t like long names. One warning, however, I couldn’t get rid of; this was because the classpath was longer than 64 characters, and Flash doesn’t allow you to have linkageID’s longer than that. So, for the time being, unless I can find out why MTASC can’t inject the class into the existing SWF correctly, I’ll just have to refactor it to get it to compile without warnings.

    The 20 minutes of code changes were local variable definition changes. Basically, this is the ONLY THING I have found different to coding for MTASC vs. for Flash. It doesn’t like inner defined local variables (like in nested loops and if then statements), nor does it like the same variable name typed twice in the same function. Naturally, I thought this was bs, but before communicating such, I asked a co-worker who was more experienced, and asked what he thought. After explaning on how other languages don’t allow you to do both of those things, and why it is ambiguous, and leads to errors where a function is dependent on a variable to be set (which is really bad for Flash since currently, it won’t throw exceptions for such things), so I understand why it’s bad to code that way, and it makes sense. Thus, I believe it’s a good thing why MTASC doesn’t support this bad practice, and I have no problems adjusting my coding style for it.

    Still, though, I wish we could get more official reports on the integrity of SWF’s MTASC generates. I am not sure what I mean by official, but I guess like real-world projects that have been deployed to big clients, thus giving me faith in the quality of SWF that MTASC can produce on it’s own vs. SWF’s created in Flash that it just injects classes into.