Language…
8 users online: DanMario24YT, Fozymandias, JPhanto,  K.T.B., Majink12, Maw, Rhubarb44230, simon.caio - Guests: 246 - Bots: 293
Users: 64,795 (2,378 active)
Latest user: mathew

Lunar Magic suggestions and discussion (LM v3.40)

Tool

Originally posted by Shiny Ninetales
Not sure if there's something wrong in my computer, or Windows or something, but something weird happens when I open the Help Contents from Lunar Magic: the Help window will always have priority over Lunar Magic, as long as they are both maximized (so, for example, if I want to change to Lunar Magic window from the Windows Toolbar, it won't work, the Help window will takeover).


That's exactly how Microsoft designed it to work (at least with the .chm help system, the older .hlp system didn't do that), which is why you see that in a number of programs. I imagine it's intended to let you have a non-maximized help file open with a maximized program window behind it so you can do things in the program while reading the help file. Developers can apparently avoid it by just not giving the help file a window handle to attach itself to (or probably by launching it through the shell), but as you've noticed users can do that as well by just running the help file themselves instead of through the program.

Originally posted by Shiny Ninetales
When they're both maximized, Lunar Magic shows 2 "tabs" in the Toolbar, but if you minimize first the Help window and then the Editor window, it will show only 1, and this can happen randomly too, sometimes the Help window tab just seems to dissapear.


LM doesn't talk to the taskbar at all. So its behavior is entirely up to Windows and whatever options you've set up for it.

Originally posted by Rykon-V73
Perhaps this should be mentioned, but the Spike Top shows up after the screen where Mario appears. If you place one at screen 0 and Mario comes out of the pipe from screen 0, the Spike Top isn't there.


I just tried it, but it seems to show up for me...
I found a bug:

Even if you implemented the line-guided outlines, the "Act as" for the line-guided tiles won't work.
This happens when you put GFX header for "Rope 1", "Rope 2" and "Rope 3".
Originally posted by Roberto zampari
I found a bug:

Even if you implemented the line-guided outlines, the "Act as" for the line-guided tiles won't work.
This happens when you put GFX header for "Rope 1", "Rope 2" and "Rope 3".


That's a bug with the original SMW code not Lunar Magic and there's already a fix for it granted it'd be nice if that fix was implemented in LM automatically but not that big of an issue.
I heard from MolSno's ExAnimation tutorial that AN2 files can only be 7 KB big at most instead of the usual 8. What does LM use the remaining 1 KB for?
My Mode 0 guide.

My Discord server. It has a lot of archived ASM stuff, so check that out!

It's actually 6.75 KB, and it has to do with how much space there is in RAM for the ExAnimation file. Lunar Magic decompresses it to $7EAD00, which is the buffer used to hold decompressed graphics before transferring them to VRAM, and then just leaves the data there while the level is running. If it uses all of $7EAD00-$7EC7FF, that's 0x1B00 bytes, or 6.75 KiB. Any larger than that, and it would run into the Map16 tile table.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
I understand now. Thanks, imamelia.

I'd like to suggest something related to the LM GUI itself and not something as overboard as adding the ability to edit the Mode 7 levels: the ability to resize tiles flexibly in the overworld, layer 3 (BG and OW border), and layer 2 BG editors just like in levels. And also the ability to fill tiles with Ctrl+Shift+right click in the layer 2 BG editor, as that doesn't work at the moment.
My Mode 0 guide.

My Discord server. It has a lot of archived ASM stuff, so check that out!

I'm sure this has been asked before, but I'll ask again because I don't remember the answer (if there was any).

Are there any plans to let us use external graphics or unloaded graphics in SP1-4 as display data for sprites in Lunar Magic?
Just for the sake of having something displayed instead of the ugly pink X in a black square for these sprites that upload their data directly to VRAM without using LM's ExAnimation. I guess something similar could be applied to Mario's tiles in the editor itself.

Letting us use other pages that aren't in the 0-0xB range for sprite map16 data could help a little bit with this I think.
Originally posted by FuSoYa
Afraid I have no plans or interest in doing ports of LM for Mac or Linux. But from what I've heard Wine has been able to do an ok job of running LM for a fair while now (so long as you're not using a super ancient version of Wine).


Hey, what if you allowed someone you trusted to port it to one of the other OSes? LM would remain closed-source, you wouldn't have to port it yourself AND it would make hacking more accessible. It should be fairly smooth sailing as long as you make it clear to the porter that you don't have time for you giving a bunch of feedback or bug-hunting on the port.

For what it's worth, while there's the possibility that the porter could maliciously leak out your source code, SMWCentral's mods are on top of their game regarding sniffing out illegal files. I've even seen someone get a warning for ACCIDENTALLY uploading a .smc for a contest level. Not to mention I'd think if anyone had the skill to port LM, they'd probably be a well-known person in the community (i.e. like Vitor) with eyes on their actions.
Pretty sure you're barking up the wrong tree Fusoya has made it very very clear over the years that he has no intention at the current moment to release his source code nor does he have interest in porting it to other OSes as sad as that is (talking about ports no the source code).

Besides Wine on Mac and Linux works just fine for Lunar Magic and most other programs either have OS ports or you can compile your own for your OS, it's really not that big of a problem anymore.
I mean, Mac/Linux users have the right to a version of Lunar Magic that runs on their operating system.
Originally posted by P-Tux7
I mean, Mac/Linux users have the right to a version of Lunar Magic that runs on their operating system.


No you don't.

Casual reminder that this is a free program made over the course of many years by one person who could very easily stop working on it on a whim. Please remember that before you come in here talking about your "rights".
That's kind of bleak for non-Win users lol (not trying to start anything)

I am starting to study SMW's code and learning high level programming so I can work on an open source, portable editor, for what it's worth.
Not out of spite or competition or anything, just out of charity to the community. I'm also doing studying so I can make more in-depth ASM hacks but that's beside the point.

If I ever get anything off the ground, maybe that should please the people that ask Fu for open source stuff.
I'd also keep the code well documented so anyone could pick it up if I or anyone else stopped working on it.

I'm still sorry for that incident where I got people upset over open source nonsense back in like 2018.
And also that thread where I said that new folk should continue pushing SMW hacking to new heights. To atone I'll just force those ideas onto myself lmao

Again, I'm not trying to fan the flames, I'm sorry if it comes off that way.
HackPortsASM"Uploader"

An "install all lunar magic hijacks" button that instantly installs all hijacks could be useful, especially for asm development. So I don't have to mess around in a new rom dragging around random objects and stuff just to get lm to install certain hijacks.

Bonus points if you can tick on/off certain (rare) hijacks.
Originally posted by AnasMario130
I'd like to suggest something related to the LM GUI itself and not something as overboard as adding the ability to edit the Mode 7 levels: the ability to resize tiles flexibly in the overworld, layer 3 (BG and OW border), and layer 2 BG editors just like in levels.


I can see some appeal to doing it that way when you're used to doing it in the main level editor, even though it's sort of redundant. Might be something to think about adding in the future, though not sure about putting that in the overworld editor... 8x8 tiles are truly tiny, and having a resizing border on them could get in the way of grabbing them for moving unless you're zoomed in.

Originally posted by AnasMario130
And also the ability to fill tiles with Ctrl+Shift+right click in the layer 2 BG editor, as that doesn't work at the moment.


Yes, should probably add that.

Originally posted by lx5
I'm sure this has been asked before, but I'll ask again because I don't remember the answer (if there was any).

Are there any plans to let us use external graphics or unloaded graphics in SP1-4 as display data for sprites in Lunar Magic?
Just for the sake of having something displayed instead of the ugly pink X in a black square for these sprites that upload their data directly to VRAM without using LM's ExAnimation. I guess something similar could be applied to Mario's tiles in the editor itself.

Letting us use other pages that aren't in the 0-0xB range for sprite map16 data could help a little bit with this I think.


For dynamic sprites, I assume? Not really plans, just idle thoughts on how I might go about it if I did put something in for it. Probably either by adding a setting that lets you set a sprite's base GFX offset or by making it possible to assign the same thing to individual sprite Map16 pages. The former is more flexible but it'd make figuring out what you're looking at in the Map16 editor pretty annoying, so the latter may be preferable.

Originally posted by Ragey
An "install all lunar magic hijacks" button that instantly installs all hijacks could be useful, especially for asm development. So I don't have to mess around in a new rom dragging around random objects and stuff just to get lm to install certain hijacks.

Bonus points if you can tick on/off certain (rare) hijacks.


Not really worth the time and effort to implement and maintain.
Originally posted by FuSoYa
For dynamic sprites, I assume? Not really plans, just idle thoughts on how I might go about it if I did put something in for it. Probably either by adding a setting that lets you set a sprite's base GFX offset or by making it possible to assign the same thing to individual sprite Map16 pages. The former is more flexible but it'd make figuring out what you're looking at in the Map16 editor pretty annoying, so the latter may be preferable.

Yeah, I've suggested this before as well, mainly for my altered spriteset system, though dynamic sprites would also benefit from it.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Actually probably the best way would be to add a new way in the sprite tooltip file to set the base GFX offset for a range of sprite Map16 tiles. That way you could still do it by page, but would have more granularity in case it's needed.

Then for external graphics, I could have LM load up to 8 "ExternalGFXNN.bin" files that could be up to 32KB each (0x8000 bytes). Which would give 0x20 pages for 0x2000 8x8 tiles to use in displaying those kind of sprites in the editor.

That or maybe split the space up into more files... that would slow reloading in the editor but might be more convenient for some people depending on what they're working with (8KB files would be a page per file for 0x20 files, or standard 4KB files would give you 0x40 files).
Originally posted by FuSoYa
Originally posted by AnasMario130
I'd like to suggest something related to the LM GUI itself and not something as overboard as adding the ability to edit the Mode 7 levels: the ability to resize tiles flexibly in the overworld, layer 3 (BG and OW border), and layer 2 BG editors just like in levels.


I can see some appeal to doing it that way when you're used to doing it in the main level editor, even though it's sort of redundant. Might be something to think about adding in the future, though not sure about putting that in the overworld editor... 8x8 tiles are truly tiny, and having a resizing border on them could get in the way of grabbing them for moving unless you're zoomed in.


Wait, for resizing 8x8 tiles, you could add a simple shortcut to go with left-click, like Alt + left-click. But you should not forget that Layer 2 BG tiles are not 8x8; they are 16x16. So we should be able to resize those as well directly with left-click.
My Mode 0 guide.

My Discord server. It has a lot of archived ASM stuff, so check that out!

Originally posted by FuSoYa
Actually probably the best way would be to add a new way in the sprite tooltip file to set the base GFX offset for a range of sprite Map16 tiles. That way you could still do it by page, but would have more granularity in case it's needed.

Then for external graphics, I could have LM load up to 8 "ExternalGFXNN.bin" files that could be up to 32KB each (0x8000 bytes). Which would give 0x20 pages for 0x2000 8x8 tiles to use in displaying those kind of sprites in the editor.

That or maybe split the space up into more files... that would slow reloading in the editor but might be more convenient for some people depending on what they're working with (8KB files would be a page per file for 0x20 files, or standard 4KB files would give you 0x40 files).

Honestly, I'd be fine with having just one giant GFX file to take all the sprite display graphics from. It wouldn't get inserted into the ROM, so the size wouldn't matter. 64 KiB or 8 KiB would also make sense for sizes.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Originally posted by AnasMario130
Wait, for resizing 8x8 tiles, you could add a simple shortcut to go with left-click, like Alt + left-click. But you should not forget that Layer 2 BG tiles are not 8x8; they are 16x16. So we should be able to resize those as well directly with left-click.


Yes if I end up doing it, it'd probably be like that or something similar.

Originally posted by imamelia
Honestly, I'd be fine with having just one giant GFX file to take all the sprite display graphics from. It wouldn't get inserted into the ROM, so the size wouldn't matter. 64 KiB or 8 KiB would also make sense for sizes.


I wouldn't mind one large file either, less to manage that way. But on the off chance that someone might want to insert them... maybe I'll just stick with the 32KB files. That's still small enough to insert if someone really wants, plus it also happens to exactly match the maximum number of 8x8 tiles Map16 data can access before changing the GFX base (0x400 tiles for 4 pages).
I forget if I asked already, but would this be worth including in Lunar Magic? (See a couple posts down for a code update.)

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

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

Tool