Language…
15 users online: Astrakitu, Batata Douce, Blizzard Buffalo, Foxy_9000_, Fozymandias, Housemeister, Ice Man, MorrieTheMagpie, OrangeRock57, ppp9q, schema_tuna,  shovda, sinseiga, temsuper1, Tsquare07 - Guests: 242 - Bots: 296
Users: 64,795 (2,376 active)
Latest user: mathew

Lunar Magic suggestions and discussion (LM v2.52)

Link Thread Closed
  • Pages:
  • 1
  • 2
  • 3
  • 4
  • 5
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
Originally posted by FuSoYa
I'm afraid that gets rather hard to justify spending my time on.

There's several other users around here who'd be willing to spend that time. Me, for example.
<blm> zsnes users are the flatearthers of emulation
Originally posted by Hinalyte
Add the option to see the directory of your ROM in the program's title. That'd make multi-tasking easier and it'd help avoid confusion when you have two ROMs opened!


Maybe. Someone was planning to do a program meant for the custom user toolbar that would do this, but think he's been MIA for a while now...

Originally posted by Noivern
How many people need to suggest this feature before you actually consider it?


It's been considered. See my last post.

Originally posted by Noivern
But your arguments that saving overworlds to file is not necessary are quite honestly bad. You are simply pretending the benefits do not exist.


No, I am not. Go back and reread my post.

Originally posted by Noivern
This is insulting.


It's not, but whatever. If you want to take it personally for some odd reason, that's up to you. You clearly aren't interested in what I have to say though, and I think I've wasted enough time on this, so consider this discussion to be over.

Originally posted by Alcaro
Originally posted by FuSoYa
I'm afraid that gets rather hard to justify spending my time on.

There's several other users around here who'd be willing to spend that time. Me, for example.


Noted. If I invent a time transference device, I'll let you know. #ab{;)}
Originally posted by FuSoYa
If you want to take it personally for some odd reason, that's up to you. You clearly aren't interested in what I have to say though, and I think I've wasted enough time on this, so consider this discussion to be over.


The insulting part was that you decided to talk down to me to get your point across.

Originally posted by FuSoYa
Originally posted by Alcaro
Originally posted by FuSoYa
I'm afraid that gets rather hard to justify spending my time on.

There's several other users around here who'd be willing to spend that time. Me, for example.

Noted. If I invent a time transference device, I'll let you know. #ab{;)}


I found one.
Very very minor issue


-Show ID in Add Object/Sprite Editors
-Correct Fatal Errors
-Silently add Header to ROM

those messages occur mojibake due to ’ (0x92) on japanese environment.
It would be nice to have LM show you where the creating snake block paths go, like you could make them transparent used blocks showing the path or something. It would take a lot of the guesswork out of trying to find where the darned thing goes.
Hi, I'm a signature!
Hack Thread
Hack Testing Status: Available.
Layout by Koopster.
Except that blows up immediately if someone edits the path. Or uses the advanced creating block, how would you even detect that this sprite is active, let alone its path?

I suspect the best solution would be someone making a tool turn the paths into ssc files. (Do they support transparency? They should.)
<blm> zsnes users are the flatearthers of emulation
Originally posted by Akaginite
those messages occur mojibake due to ’ (0x92) on japanese environment.


Looks like it got copy/pasted from the help file, which was converted from the old original .hlp help file, which in turn was compiled from an rtf document in Microsoft Word back in the day. Thanks, I'll replace them. Might as well purge it out of the help file too to avoid that happening again.

Originally posted by Alcaro
I suspect the best solution would be someone making a tool turn the paths into ssc files. (Do they support transparency? They should.)


Yes, they do.
It would be nice to have option to automatically disable animations(#lm{ani}) when LM is on the background/looses focus, with animations set to 60fps I noticed some lagginess on my pc when I have LM running in background(and it gets worse if I happen to have multiple LM's running or OW editor(s) too).
With the Eating Block Path, this is easily done if you're not lazy. All one really has to do is look at the ASM and do some math and calculations, this becomes rather simple since some of the custom sprites Creating/Eating blocks use the exact same paths as SMW and tell you how to read it. After that it's simply a matter of mapping the path out yourself.

The Advanced Block's existence makes this argument even worse since you can use the transparency features on the custom blocks that the Creating Block will follow. In all honestly, such a feature would be a good example of a "waste of time".
Just a suggestion, but the whole importing and exporting overworlds debacle has made me think: what if LM supported external plugins? Although you might have to put in extra work for establishing a syntax and all that, it would probably cut down on the feature requests.
Originally posted by KDeee
It would be nice to have option to automatically disable animations(#lm{ani}) when LM is on the background/looses focus, with animations set to 60fps I noticed some lagginess on my pc when I have LM running in background(and it gets worse if I happen to have multiple LM's running or OW editor(s) too).


Something to think about I suppose. Though you can also minimize copies of LM that you aren't using, which already suspends animations.

Originally posted by MrMrMANGOMILK
Just a suggestion, but the whole importing and exporting overworlds debacle has made me think: what if LM supported external plugins? Although you might have to put in extra work for establishing a syntax and all that, it would probably cut down on the feature requests.


It's been suggested and rejected before. It'd have to be far too broad of a framework to do what people apparently expect of it, and I don't have much interest in spending large amounts of time to turn LM into some sort of general purpose platform for modifying SMW.
I'd suggest to also add an option where the game autosaves when you start a new file, even if Mario's starting position on the overworld is moved from its default location. Maybe by having Mario walk there like he does to Yoshi's House, since I'm assuming that's what triggers it. If this isn't possible, you at least could add an option to restore the default starting position and thus turn the auto-save back on. Apologies if there's already a way to do either of those, but I haven't found it.
This is a bit late, but if you're not going to add a function to Lunar Magic that allows one to easily import/export overworlds, then I'm going to fill in that gap via ASM patches. I've already made a patch that extracts roughly 95% of the overworld data (only exception that I know of is the 6x6 event tile area setting) into a format similar to MWL that I refer to as MWO (Mario World Overworld), and I've got the import patch about 50% done. However, in order for the import patch to work, I have to include a lot of Lunar Magic's ASM code for overworlds. Not only does Lunar Magic add/remove hijacks in certain cases (ex. Whether or not the overworld has a custom palette or what the state of the "Use Colors From ROM for Lightning Animation" setting is), but I want this patch to work as closely as possible to how importing/exporting overworlds with external files would theoretically work in Lunar Magic.

Admittedly, I can see a good reason why you didn't feel you had the time to do this. Not only are there a ton more things that need to be accounted for compared to levels (My extract patch currently extracts 56 things, though that number is higher if you count certain things individually, like the Special Message level numbers), but there is also the fact that Lunar Magic supports multiple versions of SMW, plus the SA-1, FastROM, and SuperFX patches, all of which would have some effect on importing/exporting overworlds in some fashion. I can only imagine how much testing you have to do whenever you go to add a new feature. XD

Edit: Oh, add the LM compression setting to the things that would affect exporting/importing overworlds, because I just found out that at least 2 things get compressed with LC_LZ2/3 compression. This actually complicates things a bit. I'm not looking forward to figuring out how to account for that... #smw{-_-;}
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.
Originally posted by yoshifanatic
However, in order for the import patch to work, I have to include a lot of Lunar Magic's ASM code for overworlds.


I'm sorry, but you do not have permission to distribute LM's ASM hacks in source form. I could possibly make an exception for it in compiled binary form, if you want to go that route.

Originally posted by yoshifanatic
I can only imagine how much testing you have to do whenever you go to add a new feature. XD


A fair amount. It does concern me a bit that LM's support for the lesser used ROMs (SMWj, SMAS+W) might have undiscovered issues that no one knows about as they simply aren't used much. In hindsight I probably shouldn't have bothered adding support for those 2 in the first place, but oh well... it'd be a waste to drop them now.
Originally posted by FuSoYa
I'm sorry, but you do not have permission to distribute LM's ASM hacks in source form. I could possibly make an exception for it in compiled binary form, if you want to go that route.


Alright. Well, I'm glad I mentioned it before I eventually finished and posted these patches.

Also, yeah, I can go that route. How would you prefer me to handle it: via db/dw/dl/dd $XX within the patch or via external bin files? The former would be more flexible for me and be less messy, but I could probably make it work with the latter if you feel that would be "safer". I could also include a .BPS patch that makes LM install most of its hijacks and then use org readX() commands for most stuff that needs to update, but I'd have to use one of the other methods anyway for the hijacks that Lunar Magic removes when you disable certain things.

In addition, after the patch is done, I'll let you look at these patches before releasing it if you want to review them to make sure I don't accidentally leak any LM ASM.

Originally posted by FuSoYa
A fair amount. It does concern me a bit that LM's support for the lesser used ROMs (SMWj, SMAS+W) might have undiscovered issues that no one knows about as they simply aren't used much. In hindsight I probably shouldn't have bothered adding support for those 2 in the first place, but oh well... it'd be a waste to drop them now.


I can see why you'd probably add support for the J ROM initially, although supporting SMAS+W does seem like an odd choice. I wonder how many people actually use these two versions?

Just for the heck of it, I have messed around with the J ROM a bit to add support for it in my patches specifically because LM supported it (as I said, I want this patch to work as closely as possible to how LM would likely handle this). If I find anything that breaks in LM, I'll let you know. Also, I decided to add a hijack in my patches that allows the J ROM to have the "Use L+R to reenter castles" feature that the U.S. version has. It's basically just the code found in the US version, but accessed through JMLs:

Code
org $04910F
autoclean JML AllowCastleReentryJapan

freeram
AllowCastleReentryJapan:
	LDA $17
	AND #$30
	CMP #$30
	BNE .NoLR
	LDA $13C1
	CMP #$81
	BEQ .EnterLevel
.NoLR
	LDA $16
	ORA $18
	JML $049112
.EnterLevel
	JML $04915E


Feel free to add this hijack to LM if you feel like adding it. If not, that's fine.



Edit: Thinking about it, I think in the absolute best case scenario, the only hijacks I'd need to include are the ones whose existence in the ROM determines if X is on/off. That includes both routines and hex edits. Although, I do have to include a few more, because I want my patch to have the ability to add/remove certain hijacks for the purposes of allowing one to save ROM space (ex. If the imported overworld does not use the extra star/pipe indexes, then my patch will remove the LM Extra Star/Pipe Indexes ASM and then put the data in the original location. But if it does use them, then it installs that ASM and inserts the tables in the expanded area).

Also, I plan on adding some hooks into LM's code in order to add some extra functionality to overworlds, some of which could potentially be features that LM could add in a future version. One idea I had was:
adding a hook to the OW ExAnimation Init routine that allows one to sacrifice global ExAnimations to have a second set of local ExAnimations for each submap. If one doesn't need animations that play on every submap, then this effectively doubles the amount of ExAnimations you can have as long as you're mindful of V-Blank limits. This could also apply to levels as well.
I could see that being implemented into LM and I have a good idea of how it would work. However, the biggest issue I can see is that it could possibly break backwards compatibility a bit.
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.
Originally posted by yoshifanatic
Also, yeah, I can go that route. How would you prefer me to handle it: via db/dw/dl/dd $XX within the patch or via external bin files?


Either way is fine with me.

Originally posted by yoshifanatic
In addition, after the patch is done, I'll let you look at these patches before releasing it if you want to review them to make sure I don't accidentally leak any LM ASM.


You'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.

Originally posted by yoshifanatic
I can see why you'd probably add support for the J ROM initially, although supporting SMAS+W does seem like an odd choice. I wonder how many people actually use these two versions?


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

Originally posted by yoshifanatic
If I find anything that breaks in LM, I'll let you know.


Alright, thanks.

Originally posted by yoshifanatic
Feel free to add this hijack to LM if you feel like adding it. If not, that's fine.


Ehhh... I'll save it someplace in case I change my mind, but I'm fairly sure no one's doing much with SMWj so there's probably no point in adding extra ASM hacks just for that ROM.

Originally posted by yoshifanatic
adding a hook to the OW ExAnimation Init routine that allows one to sacrifice global ExAnimations to have a second set of local ExAnimations for each submap. If one doesn't need animations that play on every submap, then this effectively doubles the amount of ExAnimations you can have as long as you're mindful of V-Blank limits. This could also apply to levels as well.


It'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.
Originally posted by FuSoYa
Either way is fine with me.


Originally posted by FuSoYa
You'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:

Code
JSL LM_CustomLevelNames
RTS


as:

Code
db $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. :P


Originally posted by FuSoYa
Very 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 FuSoYa
It'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.
Originally posted by yoshifanatic
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)?


If it's just a JMP/JSL/JSR/RTL/RTS snippet for hijacking with an extra opcode or two to make it fit, I wouldn't worry about it. Same thing for small edits, unless it's going beyond 3-4 lines or so.

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


It doesn't work the other way because of the RAM layout. The global slot frame counters were intentionally stored right after the local ones in RAM (and same thing for the DMA slot RAM). So when you sacrifice global for local, the local counters array can simply overflow into the global ones. Do it the other way though and the global counters will overflow into RAM meant for DMA, which is just going to mess things up.

Of course, you could use a bit of ASM to swap the local and global list pointers and sizes in RAM to solve that. But I don't see much use for it either.

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


Perhaps, though they really would have to know what they're doing as far as vblank limitations go. Doing more in fewer slots tends to be the better choice when possible. The vanilla game can barely handle all global and local slots going at once with just the 4 8x8s line type. I guess the question is, how many people would be able to make proper use of it?

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


Alright, no promises on LM inclusion but should be interesting to see what you come up with. #ab{:)}
Is there a way to have custom external graphics files, specifically for use with sprite Map16? External versions of GFX32 and GFX33 are already supported, so having the ability to add external graphics files would make it easier to add markings or display dynamic and similar sprites whose graphics aren't in the level's graphics.
Fusoya? Do you have plans to convert all the sublevels in playable levels?
I mean, 512 levels to play.
  • Pages:
  • 1
  • 2
  • 3
  • 4
  • 5
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
Link Thread Closed