Patch remoderation thread

What was my vote of "yes for config files, but I don't care about the extension" actually counted towards?

Anyways, speaking of config files, since "yes for big patches" seems to be winning, I'd like to voice my concerns with that approach once again. That seems needlessly inconsistent to me as something to standardize. It just means that people will always have to search for the settings for every patch instead of them being in a consistent location. At that point, I don't know how much sense a standardization even makes and we might as well leave it as "up to the patch creator".

Also one thing that we haven't discussed yet: what about patches that are hosted on GitHub by someone? Specifically patches that include a GitHub link in their submission. Should we have some kind of rule like "if a patch is officially hosted on GitHub, the refactored version should be submitted as a pull request"? Otherwise the refactoring will potentially just cause a lot of headaches to the respective patch creators if they want to maintain their stuff later, because they have to manually find and merge all the changes, which really doesn't seem like an improvement in any way.

---

Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!

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:



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.



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.



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??')



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).



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.



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.



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.

---

GitHub - Twitter - YouTube - SnesLab Discord

You're probably thinking of a different kind of "shared library" than what Asar can currently provide. You're probably thinking more of "shared subroutines", like some tools already provide (or try to provide). A shared library via Asar would be something different from this. It would really just be a collection of asm files that every patch could include via a standard path if needed. Basically something like the C standard library. The benefit here wouldn't really be in saving space, but in code cleanliness and maintainable. Think, for example, about how many patches probably use some kind of "hex to decimal" conversion routine, usually with some custom implementation or some copy-pasted code. And now imagine the original routine that was copied by everyone actually contained a bug. Now suddenly all of those patches contained this bug. With a shared library, one could have this routine in one central place for all patches to use. Found a bug in one of the routines? Just fix it in the shared library and it will be fixed for everyone. Using this approach would still produce copies of the routine for every single patch using it, but only in the binary output, not in the source code.

Another benefit of a shared lib - although I'm well aware that 99% of coders here don't care about that at all and that it's probably just me - would be that it could make code more readable and intuitive. For example, we've gotten pretty used to seeing code like



but if you think about it, that's actually quite unintuitive. You basically need to know exactly what $19 stands for or look it up in the RAM Map to work with this code. Personally, I'd much prefer seeing something like



Yeah, it's a bit more text, but also self-descriptive and intuitive. Sure, $19 isn't really the best example to name here, because every patch writer here probably knows what $19 contains, and I know that we have a bunch of coders here who would rather safe the 9 characters than to have self-descriptive code, but just imagine $19 being a more obscure or rarely used RAM address that noone was likely to know without looking in the RAM Map. In that case it would be quite useful to have (and enforce) the use of some kind of shared definition. Also think about how easy this would make SA-1 conversion of patches (or even conversion to entirely new architectures). No more



in every patch. Instead, we could just change the definition of a variable in the shared library based on our architecture. The majority of patches wouldn't even have to do any SA-1 conversion at all anymore. IMO, that's a pretty good argument supporting shared libs.



That's a good point you brought up here, and one that I completely forgot to think about, despite it actually being relevant to one of my patches. I kinda forgot about this, but my VWF patch doesn't actually expose all of its defines in its .cfg file, only the ones that could reasonably make sense to be changed by average users/non-coders. It does have tons of other defines, but those remain in the .asm file as they're really meaningless to people who aren't trying to directly modify the patch or just aren't familiar with coding. IMO, this split actually makes sense and is a good idea. It's one case where I actually support putting into the .asm file. My .cfg file, as the extension implies, is really intended as a configuration file (or a setting file, if you will), influencing the patch's behavior, and it really only makes sense to expose this as a separate file if it can be reasonably assumed that it could make sense for average users to change this. IMO, this is a way more important distinction than saying "if we only have X defines, they go into the .asm file, if we have more than that, they go into an external file with whatever extension". If your patch only uses a single define and this define only really makse sense to modify if you're familiar with code, then sure, put it directly into the .asm file. However, if your code contains settings that make sense to be modifyable even by average users or novice programmers, then put it into a separate file, even if it's just a single define.

---

Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!

Regarding the libraries: It also makes really sense to include them for enhancement chips. Specifically, Super FX features many registers which both, the SNES itself and the chip interact with (most notably the R-registers which most of them are the equivalent to the A register). And the SA-1 pack also expands so it's also nice to not have to include all the defines in the ASM but in a shared library.

I would say we should have a FAQ linking to a tutorial on how to use SA-1 addressing and other things to make it compatible (as well as how to make patches a hybrid so that moderators can sit back while patch user learn how to convert them). Remember the tedious graphics remoderating? We now added a requirement to do certain things if it is past a certain date.



I would say yes, especially when it comes to code that runs every frame. This is an example that is easy to convert to uberasm.



I would say no, we should do this instead: When designing a patch, in the readme should show all the ORG address as well as the number of bytes ommited, something like this:

in patch:


Would say this in the readme:



Because there is a tendency that people might update their patches, which potentially alter the address and/or the number of bytes being modified. So should that happen, the patch maker must go to the hijack section and update that as well. Have that in the submission requirement.



Good thinking! I would say yes. It is common that people keep complaining that despite no ORG conflicts, patch A might screw patch B because of RAM conflicts (say $60-$63 is used for screen scrolling pipes, but the health patch is also using $60-$63 for displaying a graphical bar, messes up the pipes). But keep in mind that sometimes a resource might need a RAM the patch is using, for example, a ground pound patch and a ground pound block and a ground pound patch.

---

Give thanks to RPG hacker for working on Asar.

Shared libraries: It would be nice in theory, but I feel like it wouldn't work in practice due to conflicting standards for code syntax, define names, and importance of routines and things. Who decides whether $00F606 is "KillPlayer"/"KillMario"/"PlayerDeathRt", whether $19 is "!RAM_PowerUp"/"!PowerUpState"/"!PlayerPowerup", whether $E4 is "!SpriteXPosLo"/"!RAM_SpriteXPos"/"!SpritePositionXL"/"!spr_posXL", or whether SubHorizPos is "SubHorizPos"/"SubHorzPos"/"ssr_HorizPos", for instance? And what about the cases where an address is obscure enough that even a description doesn't help much, or the description has to be extra-long? Would anyone immediately guess that !OWEventTileSize refers to $1B84?

Configurable patches: I don't think they need a separate file just for configuration. A section in the ASM file just for configurable stuff, delineated by some kind of divider, should be fine. Though if separate configuration files do become a thing, I agree with not having them as .cfg files because of confusion with sprites. Maybe patchname_cfg.asm?

SA-1/GSU compatibility: Again, it would be good in theory, but it seems like it might be too much work for not enough gain. It means that patch moderators essentially have to remoderate each patch three times, and there's always the worry of something that behaves differently on hardware slipping through the cracks as well.

Converting to UberASM: Yes, if a patch can be converted to UberASM, it probably should. (I assume all such code would be for the tool; I prefer the patch, but I know I'm fighting a losing battle here.)

Unpatching: Maybe. Definitely not if the unpatches don't reclaim the free space. I'm not actually familiar with how difficult it is to make these; I've always just made backups before patching.

Hijack logging: We should have patch hijacks logged somewhere, but whether they're in the hijack map or the patch info is up the community, I guess. Whichever makes it more likely that they'll stay current.

Free RAM tool: I say no. I don't know how the tool works, but how accurate and how customizable is its free RAM finder? What if you want to organize it or are using RAM that isn't normally free (such as if you're using the $7E2000 free patch, or aren't using tileset-specific Map16 and therefore don't need $0FBE)?

Bugfix patch: A single one would make sense (and in fact, such a thing has existed for a while), though yeah, it would be a pain to keep updating it.

----------------

I'm working on a hack! Check it out here. Progress: 64/95 levels.

This is pretty much a non-issue. It's something that affects every single team coding project ever (including profesionally developed games and software), and solving it is as simple as discussing, setting and documentating a coding convention and then trying to stick to that when writing individual code. Of course stuff that doesn't stick to the convention occasionally slips through, but that's rarely a major issue because the worst that can happen in this case is that some variable has an unintuitive name, making it slightly harder to find. Anything else breaking is unlikely. If this happens before release, it's also easily fixable. If it happens after release, it can't be fixed entirely (since this could break compatibility), but an alias to the actually intended name can always be added even post-release. Aside from naming conventions, details would be left up to the respective coder working on something. Every single code library ever released for anything has to deal with these problems, and there's probably millions of those. That's the best indication that it isn't really a major issue.

Finding a definition for something also won't be a major issue. For example, if you want to use $19 in your code, finding the name for it should be as simple as opening a definitions file and doing CTRL + F in it. This can also be useful for quickly finding certain addresses without opening the RAM map. You could, for example, just do CTRL + F for "coin" in that file to find all RAM addresses related to coin stuff.



Does any average coder even know what that address is used for in the first place? At the very least, !OWEventTileSize tells me anything about the variable's intent. $1B84 doesn't do this at all. Seeing !OWEventTileSize and the context it is used in probably makes it reasonably simple to figure out what it does. Seeing only $1B84 makes it a bit more difficult. Plus, comments are supported by Asar, so for complicated RAM addresses that don't have telling names, it should be easy to just add a comment to the definition giving a few minor details (doesn't really need to be as detailed as the RAM map). Anyways, I personally think that a variable name that is little telling is still most of the time better than a variable name that isn't telling at all or no variable name.

---

Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!

SuperFX or SuperFX 2?


Yes, definitely. For my hack, I made a UberASM version of my patch. I would rather use the UberASM version, and I like it more. I'll probably upload the UberASM version soon.

But there is a problem. If you, for example have a level file with Patches 1, 2, and 3 in it, if you want to create another level file with Patches 1, 2, and 4 in it, you'd basically have to insert Patches 1 and 2 twice. The solution would be to insert the code as a patch which is a function. The only thing in the UberASM file then would be just a bunch of function calls. Here's an example.







So I think all patches that are to be converted into UberASM Code instead still be patches, but using this function notation instead. It saves ROM space if you want to use multiple patches in a level, and this format makes it extremely easy to select which patches you want to use in a level.