these damned bits doing more than one thing, with only one of the uses being apparent to me, is why i often hesitate to name them at all. i'm not actually saying my way is better, since there's help in getting *something* down on paper. but should incomplete descriptions like this get a ", and ???" appended, just to convey they're still in-progress?
That sounds like a good idea, you should add that to the wiki. I noticed some descriptions where your comments add to the understanding of the bit (you have "flag target's ATB gauge to be reset?" and the RAM map has "psyche was just cleared", for example).
CPX $3EE2 in C2/0B01
looks like you talked yourself out of it.. but to chime in, i don't favor sacrificing capability just to save a few bytes.
More like I talked myself into it, except I still can't find a way to shrink C2/09D2 enough to fit a jump to C2/0B01.
1. There's that TYA.
2. I don't think the CLC is needed either (assuming the ATB multipliers are all even).
3. ???
Ahh well. If I really wanted to make a kludgy hack, I could usurp that preceding RTS. :P
For release, I'll stick with a wrapper and conserve the LDA $3EE2 in C2/0B01.
i don't favor dropping the 2048 decrementor capping. Square has in place an elegant system via C2/083F that can get Morph up and running if any turn * sets the status, not merely one command. however, to have this flexibility while avoiding nonsensical decrementors, you can't lean solely on the Morph menu code's $1CF6 check; the C2/0B01 capping needs to be there.
---
yes, you can't anticipate and cater to every hypothetical hack out there when coding a patch. but simply *maintaining* capability present in the original game isn't so much catering to them, as simply playing it safe.
I think my proposal is fairly strictly limited to the few functions already modified to create the functionality of the patch, so it creates no unexpected incompatibility. Neither should it produce any unexpected issues for users who only care about vanilla functionality. Gutting unused parts the code does make it hypothetically less robust, but not to the point of collapse under the constraints of normal gameplay.
With that being said, this is a valid point, especially in a world where it's so easy to mod the game. This is why I'm a bit gung-ho about this as long as I don't break vanilla. My idea was to provide a .ips patch that works fine within the constraints of vanilla, for people who just want to patch and play, and supplement it with an easily modifiable source file (and ample documentation) for people who want to make mods.
when did free space become THAT scarce?
If not sometime in the past ten years of bug fixes, presumably sometime not too far in the future. There are many bugs left and thrift is a virtue. :P
is it a point of pride, having a "no free space needed!" tag on one's patch? keep in mind that optimization =/= omission. many of the people nerdy enough to care about a patch's consumption in the first place will see willy nilly lopping off of Square code for what it is, rather than be impressed. now, i'm not actually saying the drops are done to impress people.. rather, i think there's a tendency to see Square's byte count usage as a watermark of sorts, that we should stay below. but given lots of their code is Swiss cheese, why?! isn't it natural that making things work right without tossing existing functionality might require more space? some patches lend themselves to optimizing (not omitting) around this, while others not as much.
I apologize in advance for the short novella I'm about to produce, but I have given this topic quite some thought and I feel ready to share my conclusions. You may have provoked this, Assassin, but it's not directed specifically at you, although I am grateful that your rhetorical aside gave me pause to think about this.
While I can't speak for others, it's not about prestige for me. I appreciate elegance, simplicity and readable code, that make interfacing with it just as simple. While I do find satisfaction in being able to fit things inline, that satisfaction naturally dissipates if I make a kludge of the code so as to make it less readable, more difficult for others to work with, or just downright ugly. However, there are several different, sometimes conflicting, requirements to consider when writing patches, and I am not above sacrificing elegance if needed to achieve a higher prioritized requirement, such as patch compatibility.
Free space requirements make it more difficult to maintain patch compatibility. If something can possibly fit inline, it's pretty important to make it do so, in my opinion, especially for .ips users who can't change where extra code goes. However, the more important consideration for compatibility is avoiding reaching out of scope or modifying unrelated functions, in order to avoid potential (and unexpected) code conflicts. This requirement of modular code naturally trumps free space thrift, but if it can be fulfilled, then the next order is to make the patch fit inline if possible.
Furthermore, one has to consider for which audience one is trying to ensure compatibility, and make allowances for their technical ability. The non-technical users generally only care about two things: functionality and compatibility out-of-the-box with other patches, and so I'll strive to deliver that to them first and foremost, knowing that people with more technical knowledge are able to more easily modify the code to fit their needs.
To that end, I feel if the code is only just robust enough to not fall apart under normal, vanilla, gameplay constraints (edge cases included) this requirement can be considered fulfilled. Unexpected behaviour unearthed by other bugs that have already been patched should not be a consideration.
The other people whom I must consider are other patch authors, whom may wish to interface with my code in the future. They can generally ensure compatibility with their own objectives through their own effort, but naturally I want to strive to make it easier for others by not complicating the code if at all possible. With all these considerations in mind, I believe that, for now, my list of priorities looks something like this:
1) Achieving the objective of the patch
2) Patch compatibility (modular code, free space thrift, expected behaviour etc.)
3) Ease of use for end-users (patch and go)
4) Being thrifty with free space for future patches
5) Ease of use for hackers/patch authors
6) Elegance and simplicity (for personal satisfaction and bragging rights)
That last one IS a point of pride for me but it must unfortunately fall below all the others if there is a conflict. Luckily, it more often goes hand in hand with most of the other requirements.
Finally, and most importantly, I still consider myself if not a novice, at least fresh off the boat to the world of assembly coding and patch making. Every project is a huge learning experience and so I try to push hard to work within the constraints of fulfilling all the requirements I set up for myself, or at least finding the best compromise. In most cases it would be fine to relax a little bit, if you already know what you're doing, but I'm still learning and would prefer not to afford myself the allowances that come as reward for experience just yet.
