Language…
13 users online: caioskii, Chambo, Dark Prince, ForthRightMC, Fozymandias, Gorry, LadiesMan217, Mischievous Marc, Rauf, Raychu2021,  Ringo, sinseiga, The_Uber_Camper - Guests: 262 - Bots: 261
Users: 64,795 (2,375 active)
Latest user: mathew

Patch remoderation thread

  • Pages:
  • 1
  • 2
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:

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

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

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

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

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

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

Quote
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.
GitHub - Twitter - YouTube - SnesLab Discord
Originally posted by Vitor Vilela
"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.


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

Code
lda $19


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

Code
lda MarioPowerUp


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

Code
lda blah|!somedefine


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.

Originally posted by Vitor Vilela
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.


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


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.

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


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.

Quote
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 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:
Code
org $00C5CE				;\fix hdma issues (like message box) when setting
	autoclean JSL FixHDMA		;/$7E0071 to #$0B ($00cde8 constantly sets $9D to $00 when $71 is $00.).
	NOP #4

org $01ED44				;\fix getting on yoshi automatically when entering
	autoclean JML GetOnYoshiExcept	;/horizontal pipes while ovelapping yoshi's saddle.


Would say this in the readme:

Code
Hijack lists:

$00C5CE 8 bytes changed.
$01ED44 4 bytes changed.


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.

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


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.
Originally posted by imamelia
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?


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.

Originally posted by imamelia
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?


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!
And it has started! Doing everything as was the most popular opinion here (hopefully).

Here's the checklist for remoderating in case anyone's interested:
* First off, convert the patch to Asar if it isn't already. Mostly this involves making the patch use Asar's freespace finder.
* If the patch consists of a NMI/game loop hijack or another common hijack and none or few other hijacks, convert it to an UberASM Tool code, but keep the patch version too.
* If the patch has lots of configuration, move that into a separate file (preferably "<patch>_config.asm") and incsrc that from the main patch.
* Make sure the patch works properly with SA1.
* If the patch has nontrivial hijacks, check that it is properly removable with the Unpatcher. If not, write a separate unpatch for it.
* Write down all hijacks and the number of bytes hijacked for each, and add them to the hijack map (or don't if you're lazy and just post them in the remoderation channel).
* Submit the new patch as an update to the old one, removing the "needs remoderation" tag, and adding screenshots/tags as necessary. Do not skip the moderation process!
I'm agree.....


















JAAJ

This layout was designed by... Me lol.



SMWMTL Version 2.28s released on September 26, 2023 !
Download now!

Still rocking Windows 7 in 2023 ! :)
Windows 10 s*cks !
Originally posted by randomdude999
Should we make all current patches SA-1/SFX compatible?

SuperFX or SuperFX 2?

Originally posted by randomdude999
Should some simpler patches be converted to UberASM codes instead?

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.

Code
; Patch 1
!Freespace1 = $xxxxxx

org !Freespace1
Function1:
; patch code
RTL

Code
; Patch 2
!Freespace2 = $yyyyyy

org !Freespace2
Function2:
; patch code
RTL

Code
; Patch 3
!Freespace3 = $zzzzzz

org !Freespace3
Function3:
; patch code
RTL

Code
; Patch 4
!Freespace4 = $aaaaaa

org !Freespace4
Function4:
; patch code
RTL

Code
; UberASM File 1
!Freespace1 = $xxxxxx
!Freespace2 = $yyyyyy
!Freespace3 = $zzzzzz

main:
JSL !Freespace1
JSL !Freespace2
JSL !Freespace3
RTL

Code
; UberASM File 2
!Freespace1 = $xxxxxx
!Freespace2 = $yyyyyy
!Freespace4 = $aaaaaa

main:
JSL !Freespace1
JSL !Freespace2
JSL !Freespace4
RTL

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.

Click the character on the right side of my layout to visit my Discord server and discuss and play and look at and get updates and sneak peeks of the games and other things I'm making.

The authors of these 2 My Little Pony fan games have removed their games from the Internet.
Rise of the Clockwork Stallions has been updated! Download My Little Pony: Rise of the Clockwork Stallions DX: Director's Cut and My Little Pony: Magic Shards now! Spread this link!

That's just a more complicated version of the uberasm library system.

If you put the files in the library folder then uberasm will handle everything, including labeling the code, finding freespace and connecting them for you.
All you have to do is make a level file that says
Code
main:
JSL <file1>_main
JSL <file2>_main
JML <file3>_main


Though I think I've already said this but uberasm really should just have the option to automatically generated this based on multiple use of one level/gamemode in list.txt.
My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.

I pretty much agree with what RPG Hacker said, especially with this:

Originally posted by RPG Hacker
Originally posted by Vitor Vilela

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.

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.

I personally am in favour of using the .cfg file extension, but that’s because I have it intuitively associated with “Generic configuration file” in my head.

As for $deadbeef|!base1 vs remap_ram($deadbeef), I personally prefer the latter, mainly because the remap_ram function handles all RAM addresses (including SRAM, the sprite tables and Wiggler data), which the usage of the |!base1 define won’t handle correctly.

  • Pages:
  • 1
  • 2