Apologies for the late reply . . . sometimes life don't grant us enough energy to do everything we want in a short timespan.
what i was typing previously:
Any section remoderation is a tedius and tiring work. And dangerous. We need to be extremely careful when changing a specific section standards to avoid certain errors similar to the part of our sprite remoderation.
The userbase and moderators should have confidence that the remoderation will be good for everyone and we won't be doing any risky action that may cause trouble later.
Before anything, we need to be aware of the purpose of our site sections:
- Share knowledge and resources around the community.
- Facility to the community use and customize the resources. A patch should not require more tools other than Asar to use it, or maybe some form of GUI patcher.
- Have good standards that balances and warrants flexibility both to the programmer (that will create the patches) and to the user (that will use the patches). We can't set up strict guidelines and standards because the programmer will not feel comfortable (see BRR Samples for example and why we have so few submissions) and at the same time don't overcomplicate things to the user that will apply the patch (that's why we only created the UberASM section last year, it would not be applicable download codes and have the user manually insert level_code, level_init_code, nmi_code, game_mode_code, etc).
Now going directly to the points:
First off: With Asar 1.60 it's possible to have a file be automatically included in all patches, making it possible to have a libary of code shared by many patches. There already exists one such library, namely RPG Hacker's shared library
, but maybe we should create a new one. Feel free to suggest functions/macros/defines that should be present there.
One idea that is related to a shared library is a set of macros and defines to allow a patch to easily specify tools/patches it is compatible or incompatible with. (See here
for an example implementation.)
Not a bad idea. "Shared libraries" (or more like, shared defines?) always help to keep our code clean and reliable, but are they really needed for patches? For blocks and sprites they are pretty useful because you can share code with, you can update them and all sprite and blocks are updated as well, but for patches uh... They're only applied once normally.
I think most of our userbase copies "asar.exe" to the patch folder and then opens it. It's practical because you don't need to type the whole patch and because it's a console application. Would you also need to copy a couple of files (and folders as well...?) to apply a patch? There's some confusion potential there for the too little benefit. Overall defines can be copy/pasted depending of the patch needs without further risks.
If we end up using this idea, I suggest integrating the .asm files inside the .exe file and when needed to update it, release a new Asar version. Because updating the shared library separately to the Asar will likely lead to confusion between the users. Additionally, when updating the shared library always
keep backwards compatibility with previous patches, essential to don't require further remoderations or undefined behavior when applying somewhat older patches.
Next: We have a few patches where things that are intended to be configured by the user are in a separate .cfg file which is included from the main patch (for example the 32x32 player tilemap patch
). Should all (configurable) patches be like this? Should we merge the configuration into the ASM file instead?
What would be the main advantage of having a separate .cfg file over merging everything? And the difference over an .asm file? I don't know but when I see a .cfg file I feel it's more like a file that I should not open by default or it's handled by a tool. So I'd prefer either they be an .asm file or don't have that file at all. I don't see myself adding a configuration file on SA-1 Pack for example because the only two options the patch offers is enabling/disabling ZSNES support and DSX. Usually people don't change those settings without knowing what they're doing.
Should we make all current patches SA-1/SFX compatible? This won't mean that new submissions must be compatible, but it will just be an attempt to make the patches section more SA-1 friendly. It will make the remoderation more time-consuming, however.
As one of the people that proposed the "hybrid" format and one that also did many ASM conversions, either static or hybrid, I think while this is definitely a very good idea for the community, the community really needs more accessibility because the SA-1 Pack is growing more and more, the work needed for converting everything is ... gigantic. Converting 1-2 patches to hybrid are okay, but once you start doing 10, 20, 30 conversions, it will get extremely tough and stressing to do each one. Checking for the data bank, SNES DMA, if a certain hijack runs by the SNES or SA-1 CPU, check PPU registers, check for CPU registers, RAM remapping, situations where both CPUs can execute the same code, situations where multiple data banks can be used, situations where data bank is $7E for whatever reason and you do STA $0100 -> STA $6100 thinking it will store to BWRAM but it's actually going to $7E:6100, the classic known crashes caused by the JMP [$0000] and you never notice without using a debugger...... and many others. You must be ready for everything.
If you guys believe that you all can do the remoderation, with good hybrid conversion and not take like 5 years, go ahead! Otherwise, I think it's just better to smoothly convert those in background though demand (e.g. help threads or SA-1 pack replies about 'hey someone has the sa-1 version of patch ABC??')
Should some simpler patches be converted to UberASM codes instead? UberASM is more versatile, in that you can have it run only in specific levels. However, some users might not like the added complexity of UberASM.
Using UberASM Tool should be less complex than using a patch. I have plans for doing an update on UberASM Tool that will allow multiple .asm files per level + an event triggering system similar to Lunar Magic's ExAnimation Triggers which should make inserting uberasm code 1000% easier to any user. With that I see no reason in keeping the codes in patch form which uses hijacks and will likely be less efficient compared to them UberASM format (not efficient as in, requiring a hijack that can cause conflict or some other awkward situation).
Should there be an "unpatch" included with every patch? My personal opinion is that if the Unpatcher tool can already handle them, then it is unnecessary to include an unpatch too, but if the unpatcher doesn't work on a specific patch then an unpatch should be bundled. I'm against including an unpatch with every patch because it increases the amount of stuff to moderate (including with updates, which might add a hijack but not add it to the unpatch, which could be overlooked), and also that unpatches by themselves have a few quirks that i've seen messed up multiple times.
No. That will increase the complexity of the patch and moderation procedure. It should be up to the author to include it or not, in my opinion.
Should all hijacks used by all patches be logged in the hijack map? That would make it easier to check whether a hijack you are about to use will conflict with another patch.
I don't see much problem in doing that and should be encouraged, mostly for the large scale patches. The Hijack Map was made exactly for that. But again, converting the possible patches to UberASM is a good start to eliminate the probabilities of hijack conflicts.
And lastly: should all patches using free RAM use my new freeRAM tool? More details will be coming shortly (I need to sort out a few things with Asar integration and SA-1), but basically, it keeps track of which empty RAM addresses have been used and which haven't, and automatically picks a block of free RAM with the necessary size. It's also possible to limit the RAM the program will select, for example only choosing from RAM that's cleared at level load or RAM in the $0000-$1FFF range. It would mean that the end user doesn't have to worry about finding free RAM, but in order to be effective, it would have to know about ALL free RAM currently used in the ROM (either by having the user manually input known used freeRAM or having all tools use the freeRAM tool too).
Too early to consider that... There's many things that need to be considered, like some free RAMs are shared across patches, others are historically fixed and known by most of the hackers, others that hackers themselves will use and can get confused and SA-1... well... you will have also to take in considering CPU accesses, speed, SA-1 Pack fixed RAM addresses and much more... And would it require using two tools for patching? Or is it an asar extension? Sounds likely that can cause more confusion, but again, it's too early to consider putting that idea for a tool that is still not totally done and used by the patch creators. And lastly but, I'm also afraid of we requiring a tool that we don't know how stable is it or it will work well on the long run.. It's a risk similar to PIXI, regardless of who is doing the tool or how it was based off.... It's a risk. I prefer waiting more time and see how well it will work in the practice.
Integrating all bugfix patches into a single one does not seem to be bad idea. I support it.
- SnesLab Discord