If you get an error other than "Out of memory" then you may be trying to obfuscate variables, functions, or labels in a program that uses CHKVAR(), CHKCALL(), or CHKLABEL().
If this is not the case, it would be very nice if you could send the un-obfuscated program to me so that I can find the cause.
CHK functions cannot be worked around without completely re-implementing the CHK function code. This uses the same principles of the halting problem, CHK function strings cannot be obfuscated without evaluating the expression, which leads to broader issues...
It might be a good idea not to obfuscate COMMON functions since they'll probably be used in another slot.
Replying to:
12Me21It might be a good idea not to obfuscate COMMON functions since they'll probably be used in another slot.
Well, from my knowledge, then the COMMON functions would completely not work if it uses global variables. I need to do more testing
My solution right now is just to combine everything into one file before obfuscation
If I find a better solution I will definitely attempt it
Maybe automatically combining all the needed files then separate them and save each one
Replying to:12Me21It might be a good idea not to obfuscate COMMON functions since they'll probably be used in another slot.
Oh, I meant to say specifically the function name.
Interesting.
You should probably have a "WHILE BUTTON()!=0:WEND" at the beginning, because pressing A just to start the program causes it to also press A on the first option which is a bit annoying.
Replying to:
amihartInteresting.
You should probably have a "WHILE BUTTON()!=0:WEND" at the beginning, because pressing A just to start the program causes it to also press A on the first option which is a bit annoying.
What about using an "on button release" for that? Or is bounce an issue?
the fact an obfuscator exists is a problem in the first place
Only Toad would see non-editable and understandable code as a problem since Toad probably wants to view how a program works against an uploader's wishes.
I'm guessing it's the quality of the obfuscation that people don't like or we have a Toad army.
I downvoted this program based on the principles established in the discussion thread. Regardless of its quality, an obfuscator does not deserve widespread use or the same level of prestige as other development tools and libraries.
Similarly, I downvoted Amihart's challenge after my solution not because of its quality but in an attempt to discourage mindless clones.
Most of the programs I've made use VAR("THING") and CALL("WHATEVER"), and considering how useful it is, I'd say many of the more complex programs for which your program would be beneficial (like for anti-cheating) would fail.
But I get why it's difficult. You COULD do a heuristic to capture the common use cases for VAR and CALL, and if a program STILL doesn't work well then they're doing something crazy.
For instance, you could search for all string literals and if they match an existing function or variable name (that you've obfuscated), you can replace the literal. This will fix both CALL("MYFUNC") and CALL(THING$) where THING$ is set to a literal SOMEWHERE.
Oh okay that makes sense.
Neat! Can't wait to play around with this.
Probably won't start obfuscating everything, but I love hiding secrets for only the most determined of players to find.
Chicken also has a problem with it
to quote the higher up comment, "The point of an open-source platform is to allow others to read and eventually understand others' programs."
”Hmm, what would be the best way for people to look at my stuff and say “Hey, what the hell is this?” Oh yeah, change very function to random lengths of _ and scatter random number throughout”.
People salty over the existence of an obfuscator because they want "free code", when they don't realize that trying to suppress the existence of an obfuscator is antithetical to that very concept.
