It's not a bad idea, there needs to be something that prevents you from blocking all the time or else it would be way op (in the new thing, you will be able to hold the button). Altho beign able to hold block as long as you like when at 100% would make it so you can always hold block and wait for the enemy to attack, then attack safely as the enemy is recharging its power%. So that gave me the idea that, as you hold block, your power% decreases and if it gets lower than 25% (or something) it goes to 0% directly, and while it is between 0 and 25 you can't block but, if you are at 100%, you can hold it for a small amount of time before it starts decreasing meaning you can try to time your block well and have the opportunity to counter-attack, or play it safe and hold it longer in times of danger where not beign hit is more important.
The bow does not yet get extra distance, but it will (altho probably less then it did in the old patch), I'd like it to have a '"rain of arrow" attack as well
As for the number of patches, if you mean patch files, only 1, but with many different selectable options
As much as I thought that keeping each feature seperate from each other would make it harder for me, it actually makes it so much easier to keep it all organized.. And makes it easier to keep compatibility with other patches, like for instance, The "MP visible at all time" thing, is not compatible with Mop's ancient cave because of how he placed his custom graphics used to display the time and floor at the same spot I used for the MP graphics. Since you can disable it, other features can still be used without the need for a different patch. It also makes it possible to include WIP features and stuff that needs testing. If you meant of many of those options there will be.. no idea, probably lots of them, but at the same time, you won't be able to choose aspects of a feature.. like say, "strong and weak attacks" will include all alternate attacks for each weapon, so the javelin melee attack and the bow's rain of arrow are both in or out.
Heres what my baby, my project development program called "Snes Asm Studio" looks like (just had to show it.. im kinda really proud of how I managed to make it all work to be honest
an ASM file:
a definition (adf) file:
Once compiled, its possible to view each line's offset of an ASM file:
Project options manager:
An asm file which will have some lines included only if some option is chosen at patching-time
It has some cool useful features like auto-completion:
Fast navigation: middle clicking a subroutine name (like after a JSR) will navigate to the sub-routine's code:
named(defined) addresses appear in yellow, named values appear in blue. middle-clicking an address or value name will navigate to the definition file where it is defined:
The compiler first reads a definition file called DEF.adf in the root folder, which will have some "FILE" instruction that tells the compiler to include other reference files.
Reference files can have a "REQ 'some option'" instruction meaning it will only be included if the specified option is used.
Reference files are responsible of specifying the path of each asm file to be added to the list of asm files that will later be processed (usually done with "DIR" instruction that will include all asm files in a directory).
Reference files can act as folders (those blue folders) so for example each feature is within a reference folder that starts with a "REQ" instruction with the feature's option name, then a "DIR <>" instruction meaning, "add all asm files in this directory (or any of its sub-directory) to the list of asm files to be processed"
Reference files can define address or values name using "/", which basically mean "if you encounter this word in an asm file, treat it as if it was this address or value"
Reference files can declare "relative" 24-bit address names (usually used for sub-routines) by using the "!" prefix : "!someRelativeSub" these will be bound to the last "relative block" (defined with the "@" prefix ie: "@E00000") but will have an undefined value until later (more on this later)
Once the compiler is done with reference files, it start processing the .asm file list
.asm files have a special instruction "@OFF 'someAddress'" that basically sets where, in the ROM, the assembled code bytes will be written.
If a @OFF instruction address is an undefined relative address like say "@OFF someRelativeSub", the value of the "relative address" will be set to the matching "relative block's offset", so using the same example as above,its value would be $E00000 so "@OFF someRelativeSub" would become "@OFF $E00000'". Then, until another "@OFF" is reached, each assembled byte will increase the relative block's offset by 1.
So if later another @OFF instruction address is an undefined relative address which is bound to the same "relative block" (@E00000) lets say.. "@OFF someOtherRelativeSub" its value will be set to the block's offset which has been increased by the number of bytes in "someRelativeSub" so, say "somRelativeSub" had 2 instructions: JSL $C00000 and RTL, so 5 bytes total, "somRelativeSub" would be set to $E00005.
Relative Addresses once set act exactly like defined addresses names, so whenever they are encountered, they are repalced by their value ie: "LDA someOtherRealtiveSub" would be replaced by "LDA $E00005".
In the case where a relative address is encountered before being defined, it is replaced by a temporary dummy value "$000000" (or any 24-bit address, doesnt matter)
Once the compiler is done processing all .asm files in the list, it starts over and do it again once more. Since all relative address should to be defined by now, no undefined relative address should be encountered and replaced by a dummy value this time, if an undefined relative address does appear, a compilation error is thrown and the programmer is judged guilty of having made illegal use of an undefined address with no possibillity of appeal.
January 13, 2017, 03:42:55 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Ok, time for version 0.02 : V0.02
it includes a new version of the patcher, the old version wont work with the new patch. The patcher now shows a little description for each option.
* Walking to the edges of the screen
* Faster Enemies (WIP, testing needed)
This makes enemies move faster/attack more frequently
* Faster chest openning
Mop asked if there would be a way to skip the "chest openning" animations, since chests drop so much more often in Ancient Cave, I found a way to make it work, and thought I should add the feature in my mod too.
* Manual blocking (well.. not really)
For now, it only shows the character blocking animation as you hold L ... it won't block attacks or anything tho
* strong and weak attacks:
the javelin melee attack is now a thrust instead of a slash
I've changed the location where my routines are written in the expanded region of the rom from E0/0000 to F0/0000, this makes it compatible (at least some of the features..) with Moppy's Ancient Cave. It is now possible to change this location with the patcher's "definitions.." button