Originally posted by FuSoYaEither way is fine with me.
Originally posted by FuSoYaYou'll probably do fine, but sure, I suppose it wouldn't hurt to take a quick look over it. Best to send via email, as a PM might not be seen for a while depending on when I log in.
Alright. By the way, what's your stance on small bits of code? Do I need to obscure simple hex edits and/or blocks of code that are really small (like, 5-7 lines or less)? I'll default to yes, although writing out:
CodeJSL LM_CustomLevelNames
RTS
as:
Codedb $22,LM_CustomLevelNames,LM_CustomLevelNames>>8,LM_CustomLevelNames>>16,$60
probably isn't going to do much to obscure it. The vast majority of LM's ASM would be big enough that I will definitely obscure it (and I'll err on the side of caution in that regard), but a single hex edit at some address or a tiny routine (like the one that one of the OW options in the Extra Options menu installs for one of its hijacks that is 6 lines/11 bytes long) doesn't seem that necessary per se, but that's just my opinion. Again, I'll default to "Obscure everything LM does except the bytes I absolutely need to modify for the code to function".
Also, I know that the example code is wrong for that specific hijack. I did that intentionally.
Originally posted by FuSoYaVery few I suspect. Even the Japanese hackers use the US ROM, so I imagine the only time people open SMWj is just out of curiosity to check out the differences from the US ROM. As for SMAS+W, the ROM has less space so you typically only see people use that when they intend to do a hack for all the Mario games in it (which is kind of over ambitious, so those tend not to get finished unless they keep things simple).
I thought that was the case as well for both ROMs. Interestingly enough, because LM now supports custom Layer 3, LM could now theoretically support text editing for the J ROM because one could swap out the Layer 3 graphics being used at a time if a different set of characters are needed in X situation. It probably wouldn't be worth the effort to implement though, as one could do the exact same thing in the U.S ROM.
Speaking of people being curious about the J ROM differences, when I was getting the offsets for the J ROM, I found something kind of interesting. At $0084C8 in the U.S ROM, there is a wrapper for the routine LoadScrnImage, but it doesn't seem to exist in the J ROM. This wrapper is only called once by a JSL in bank C, which also doesn't exist in the J ROM. I think this has something to with the fact that the U.S. version made some of the enemy names change in the credits when the special world is beaten.
Originally posted by FuSoYaIt's funny you bring that up... because I specifically wrote the ExAnimation ASM to support doing that. All you need to do is set the flag that turns off global ExAnimations for that submap, then add your extra slots to the end of the existing local animation slot list and set the size of the list appropriately. No ASM changes required.
But while the ASM support for it is already there, I never added support in LM for it. I decided it was probably wiser to encourage people to combine their slots when possible (by just transferring twice as many tiles), as it takes up less processing and a bit less vblank time than having it in a whole bunch of separate slots.
One step ahead of me, aren't you? XD That's pretty cool that you actually partially implemented this already. Just looking at the disassembled ExAnimation ASM I have didn't give an obvious indication that that was the case, but I see how it works now. I tested that out and I can confirm it works (though I tested it in a level since that was easier given how my hack is set up). Given how it's set up, I bet the opposite is true. Could one sacrifice the local ExAnimations to have double the global slots? I don't see why one would want to do that though, but I'm curious.
Funnily enough, the thing that gave me the idea for this was that I noticed that if the constants used as a pointer to the global ExAnimation data were changed into long addressed pointer tables, then this would be possible (and this is why I said backwards compatibility would break a little). If I implemented this in my patch though, I would have hijacked the bytes right before the global ExAnimation check in order to not cause issues in LM. But, I probably won't do that now. The way you implemented the ASM is better and means that my patch already supports the extra ExAnimations without any additional work.
Anyway, regarding this feature, maybe you could implement it as a hidden feature similar to, say, displaying the sprite map16 in the map16 editor? It could be another advanced ExAnimation feature for those that know what they're doing and are able to use the ExAnimation system to its potential. With FastROM/SA-1, good use of the various triggers and maybe disabling the original SMW animations if necessary, the extra processing and V-Blank use involved might not be too much of an issue either.
Also, I have a few more ideas for stuff to implement in my import/export OW patch and its level counterpart that could be potential LM features, but some of them are things I don't dare spoil before I release these patches. At least, in public anyway.
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Strange Quest V1.3 /
V1.3.1 Beta 4.6
Mario & Yoshi's Strange Quests (2/10/2023 Build)
Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.