Omnimaga

Calculator Community => TI Calculators => ASM => Topic started by: Hot_Dog on August 11, 2011, 02:28:46 pm

Title: Please avoid using "Decompile Axe" as an answer to an ASM question
Post by: Hot_Dog on August 11, 2011, 02:28:46 pm
The ASM forum on Omnimaga is where people can turn to when they are stumped with an ASM project.  Recently I've seen several questions where someone replies "Rip the code off of Axe."  We, the staff at Omnimaga, understand that such a person is trying to be helpful, but for the future, we would like to ask you to refrain from posting "Axe-cheating" as an answer to someone's ASM question.

The biggest reason for this is to continue encouraging people to ask for help.  ASM is a hard language, and we want people to know that we are only too happy to answer their questions if they're stuck.  If we simply suggest that they create an Axe program and decompile the result, we are, even if accidentally, telling them "You can take care of yourself, so get your own source code and keep trying to figure it out."  Like I said, we don't mean it that way, but it will eventually come across that way.

That should be reason enough, but here are more reasons:

1. Decompilation from Axe is not necessarily an easy process
2. Often one will learn more from getting actual help or from receving freely-given source code.  I found this true with several of my projects.
3. "Decompile Axe" is doomed to be overused as a response.  This will just be an annoyance.
4. People passionate about ASM games will work to optimize as much as possible.  While Axe is fast, it's not necessarily optimized.
Title: Re: Please avoid using "Decompile Axe" as an answer to an ASM question
Post by: Michael_Lee on August 11, 2011, 02:34:57 pm
I move that we sticky this.
Title: Re: Please avoid using "Decompile Axe" as an answer to an ASM question
Post by: Quigibo on August 11, 2011, 02:48:47 pm
I agree.  And there are many cases where Axe's code is overly complicated due to restrictions and invariants in the language, like the required use of 16-bit numbers and the hl register for instance.  Also, I suspect another reason people might say that is because they don't know ASM themselves, but are still trying to give some advice.

I do think the individual subroutines in the Commands.inc are a good source of knowledge base because they don't require disassembling and they're guaranteed to be highly optimized.  But that fact could make some routines less readable to beginners.
Title: Re: Please avoid using "Decompile Axe" as an answer to an ASM question
Post by: TIfanx1999 on August 12, 2011, 08:57:41 am
Good points here Hotdog. Decompiling can also leave out things IIRC. Also, if they are new to ASM and looking at someone else's uncommented code it would probably be more confusing then someone giving example code and an explanation. :)
Title: Re: Please avoid using "Decompile Axe" as an answer to an ASM question
Post by: Binder News on August 12, 2011, 10:19:29 am
I definetly think the routines are good to use, but I did once decompile an Axe program just for fun, and it doesn't help much. it's like decompiling the minecraft source. No variable names or anything, just a bunch of random letters and numbers. Not very useful at all.
Title: Re: Please avoid using "Decompile Axe" as an answer to an ASM question
Post by: Hot_Dog on August 12, 2011, 11:07:41 am
I do think the individual subroutines in the Commands.inc are a good source of knowledge base because they don't require disassembling and they're guaranteed to be highly optimized.

Oops...when I said "not necessarily optimized," I forgot about the Commands.inc :)
Title: Re: Please avoid using "Decompile Axe" as an answer to an ASM question
Post by: ralphdspam on August 25, 2011, 08:57:49 pm
While Commands.inc is a great resource for a lot of routines, I agree that it shouldn't be used instead of giving a comment ASM routine (that might be easier to understand).

Last month, I asked about trig functions in ASM.  The first response I got told me to look in the Axe commands.  Before I asked the question, I had already checked Axe and noticed that it didn't handle the numbers the way I wanted to.

On the other hand, I might want to decompile Axe sometime and figure out how the source parsing works.  :P