Language…
11 users online: ASMagician Maks, Green Jerry, Ice Man, kurtistrydiz, MorrieTheMagpie, Nyumi_996, Phyll, Shiki_Makiro, Sluwu, TheMorganah,  zuccha - Guests: 107 - Bots: 96
Users: 69,207 (2,358 active)
Latest user: lapakspin99

Lunar Magic suggestions and discussion (LM v3.51)

Tool

  • Pages:
  • 1
  • 2
  • 3
  • 4
  • 5
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
Originally posted by FuSoYa
Don't really see what that has to do with keeping track of slots. I think you might be confusing it with something else.


Oh wait, my bad! Didn't know what I was talking about there... Btw, I dunno how much this has been discussed before, but why doesn't (manually) transferring the OW in LM also transfer the title screen? After all, the title screen editor is only accessible in the OW editor, so it not being transferred is mildly inconvenient and unintuitive.
My Mode 0 guide.

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

Originally posted by Thomas
Would a hotkey be a happy medium? Like Ctrl with either +/-, </>, or the left/right arrow keys. That way no extra button, but leaves the option available for anyone who needs it.

Alternatively, playing along with the idea about editing the whole exanimation slot as a single text string, how possible do you think it'd be to work using text strings on the clipboard? So that you could copy a slot, paste it into a text editor to modify the data, then copy that to paste it back in LM. Not sure how compatible that is with the way LM is currently storing the data on the clipboard, though.


Yeah, those are the other 2 alternatives I had already been thinking about. While somewhat tempting, currently I'm still slightly leaning towards just having the single text field as an alternate mode at some point.

Originally posted by Anas
Btw, I dunno how much this has been discussed before, but why doesn't (manually) transferring the OW in LM also transfer the title screen? After all, the title screen editor is only accessible in the OW editor, so it not being transferred is mildly inconvenient and unintuitive.


That's not part of the overworld, so of course it's not going to transfer with it. You don't really think you're saving the title screen and credits every time you save the overworld, do you?

The overworld editor just happens to be able to serve as a generic SNES 8x8 tilemap editor. That's why it's also used for editing the title screen, credits, and layer 3 tilemaps.
Originally posted by Thomas
Originally posted by FuSoYa
Originally posted by LucasRCD
I'm still a believer that having buttons to shift ExAnimation frames by +1 or -1 should be added, as it would save a lot of time and frustration. I still have memories of having to spend upwards of an hour fiddling with this stuff because getting the timing of palette animations correctly was a pain. The time copy and pasting things manually adds up, a lot.

I don't recall what the original reason for vetoing this suggestion was, but I can imagine that adding two extra buttons to the ExAnimation windows must be a no-no for you.


True, there's already a bunch of buttons in that window. And I'm not really convinced that type of editing comes up often enough for most people.

Would a hotkey be a happy medium? Like Ctrl with either +/-, </>, or the left/right arrow keys. That way no extra button, but leaves the option available for anyone who needs it.

Honestly I'd be happy with even just the hotkeys, because it'd beat having to manually copy and paste each value and keeping track of things. It may not be something that comes up for the majority of users, but it's something us who dabble into a lot of ExAnimation, especially when it comes to syncing multiple slots with each other, run into a lot. Particularly those who make extensive use of animated hurtblocks or disappearing blocks akin to Mega Man games, who want to make use of multiple timings for them, rather than just one. Just because it's a niche scenario doesn't meant it doesn't happen.
I play forum games and draw furries. I'm mostly active on Discord and Twitter.

Hey FuSoYa!

I've just downloaded 3.40 and getting an issue i've not had before on my laptop, or as extreme on previous versions of Lunar Magic.

When clicking the 'Super GFX Bypass' dialog, it takes at least 10 - 15 seconds for it to open the window.
and clicking the 'Layer 3 GFX/Tilemap Bypass' takes around 3 - 4 seconds to open.

For further context, this is reproduced on a fresh download of Lunar Magic 3.40, with a completely clean/fresh rom.

Also checked and tried to reproduce on 3.33 and 3.31 and the 'Super GFX Bypass' window still takes roughly 2 - 3 seconds - so some kind of loading is happening in the background (as apparent with the windows loading spinner).

Running LM on Windows 11 Pro. Understand that this might be tough to diagnose as it's probably machine related but let me know if you have any advice or need any more information.
Originally posted by LucasRCD
Honestly I'd be happy with even just the hotkeys, because it'd beat having to manually copy and paste each value and keeping track of things. It may not be something that comes up for the majority of users, but it's something us who dabble into a lot of ExAnimation, especially when it comes to syncing multiple slots with each other, run into a lot. Particularly those who make extensive use of animated hurtblocks or disappearing blocks akin to Mega Man games, who want to make use of multiple timings for them, rather than just one. Just because it's a niche scenario doesn't meant it doesn't happen.


Well, I guess there's no reason why the existing < and > buttons couldn't serve a dual purpose. They could be set up so you could hold down Ctrl or Shift and use them for +1/-1 shifting, and I could just throw the new info about them into the button tooltips. Still somewhat discoverable, and no need for more buttons that way. #ab{;)}

Originally posted by JezJitzu
Hey FuSoYa!

I've just downloaded 3.40 and getting an issue i've not had before on my laptop, or as extreme on previous versions of Lunar Magic.

When clicking the 'Super GFX Bypass' dialog, it takes at least 10 - 15 seconds for it to open the window.
and clicking the 'Layer 3 GFX/Tilemap Bypass' takes around 3 - 4 seconds to open.

For further context, this is reproduced on a fresh download of Lunar Magic 3.40, with a completely clean/fresh rom.

Also checked and tried to reproduce on 3.33 and 3.31 and the 'Super GFX Bypass' window still takes roughly 2 - 3 seconds - so some kind of loading is happening in the background (as apparent with the windows loading spinner).

Running LM on Windows 11 Pro. Understand that this might be tough to diagnose as it's probably machine related but let me know if you have any advice or need any more information.


On a 15 year old PC running Windows 7, it normally takes less than half a second to open the "Super GFX Bypass" window. #ab{o_O}

The only thing that changed between 3.33 and 3.40 that could affect it is language support being added. Except that change actually made the window slightly *faster* to display in 3.40, as apparently having Windows convert from UTF-8 to UTF-16 is faster than it converting from the current codepage to UTF-16.

Mind you, there is one thing I know of that can make it 4x slower. That's by using the manifest file trick to force LM to use version 6 of the common controls. Which is one of the reasons I've never made the released version of LM use it. But even then, your laptop CPU would have to be around 300 Mhz for it to take 15 seconds. Are you sure the laptop doesn't have some kind of CPU throttling/overheating issue?

Also, you're not using some unofficial window skinning engine like WindowBlinds are you? Some of those are notorious for slowing things down pretty badly.
Originally posted by FuSoYa
On a 15 year old PC running Windows 7, it normally takes less than half a second to open the "Super GFX Bypass" window. #ab{o_O}

The only thing that changed between 3.33 and 3.40 that could affect it is language support being added. Except that change actually made the window slightly *faster* to display in 3.40, as apparently having Windows convert from UTF-8 to UTF-16 is faster than it converting from the current codepage to UTF-16.

Mind you, there is one thing I know of that can make it 4x slower. That's by using the manifest file trick to force LM to use version 6 of the common controls. Which is one of the reasons I've never made the released version of LM use it. But even then, your laptop CPU would have to be around 300 Mhz for it to take 15 seconds. Are you sure the laptop doesn't have some kind of CPU throttling/overheating issue?

Also, you're not using some unofficial window skinning engine like WindowBlinds are you? Some of those are notorious for slowing things down pretty badly.

Yeah that's what i find pretty baffling, my laptop is way more then capable.

I do get some minor CPU spikes (3.5 GHz jumps up to around 3.9 GHz) when opening the super GFX bypass window which at highest is still only using 15% of my CPU... but otherwise everything running as usual.

No window skinning engine or anything else that springs to mind. Obviously something weird going on my machine, but a little confusing that it doesn't happen on any previous version of LM.

Update: After clicking around and messing with some of the exe settings - it now opens in 3/4 seconds after setting the software to always 'run as administrator' #smrpg{sick} so i wonder if theres some weird permission/privilege stuff going on. Which still seems longer then it should.
Yeah, that still seems slow. And the administrator thing just sounds suspicious. Nothing LM is doing there requires any special permissions, and running as a normal process shouldn't make it several times slower.

You still might want to check the power profile settings for that laptop or any special software it's running to control that, in case it's throttling the CPU in some way to save power/battery.

A very severe resource leak in another program can slow down GDI processing for all programs, but that can be solved just by closing the offending program or rebooting. And it wouldn't explain the administrator difference.

The only other thing I can think of is some kind of security or virus scanner that's intercepting API calls that LM makes to monitor or perform some kind of behavior analysis, and it treats LM's exe differently if it doesn't recognize it or it runs at a different permission level. Or a third party program doing the same thing for unknown purposes.
When a level I'm working on has a "unified" entrance--i.e. it doesn't have a Midway entrance, the "Use separate settings for Midway entrance" option is unchecked--Lunar Magic will separate the entrances when I reposition the entrance with the mouse (even within the same screen), which is a bit of a nuisance to undo if that's the preferred entrance configuration for the level. I have to move the Midway entrance to the same screen as the Main entrance (if on different screens), open the #lm{1door} dialog, and uncheck the setting and hit OK, to undo it which is a lot of steps. It would be nice if LM only separated the entrances if that option was explicitly checked in the dialog instead.
That's more of a harmless cosmetic thing if you're not using midway entrances. And the current way is probably easier for those new to the program. But I guess I could just add an option for turning auto-separation off for those that don't want unused midway entrances hanging around.
Me again with another minor cosmetic thing :) It would be nice if the outline for exit-enabled tiles was a different color from the hurt outline (both are red) so they would be differentiated when all tile outlines are enabled in the view--perhaps purple or something.
They're not really meant to be used together much. Outlines from the exit enabled tiles are going to obscure the ones from the surface tiles, so you're not getting a complete picture of surface properties when you do both.

Besides which, I'm not really a fan of purple exit tiles. #ab{;)} I did consider shading the interior of exit tiles red to set them apart a little more back when I first added them, but that wouldn't help in all cases.
What circumstances can cause Lunar Magic to skip processing one-shot triggers (or other ExAnimation) entirely?

Also, how do you find the locations of ExGFX60-63 in the ROM?

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Originally posted by imamelia
What circumstances can cause Lunar Magic to skip processing one-shot triggers (or other ExAnimation) entirely?


Assuming you mean in the actual game, not LM: disabling animation, either via flags or $14 not changing. Or somehow preventing LM's ASM from even running.

Originally posted by imamelia
Also, how do you find the locations of ExGFX60-63 in the ROM?


See https://smwc.me/1594902, from the last time you asked.
Hi Fusoya,
First off, I'd like to thank you for all your work over the years on LM.

My question is related to the opening of the Super GFX Bypass menu. I think it's on all of the GFX file-related menus, actually. I noticed that, ever since I upgraded to Windows 11, those menus have taken forever to open up. Of course I'm spoiled, but it's still about 4-5 seconds every time, compared to all other menus taking a fraction of a second at the most. I thought initially that this would be related to the addition of the GFX file edit buttons in 3.30, but it still happens on older versions. I was curious to see if you had any thoughts about the cause of it for this window only, or if you think there's anything I can do on my side to reduce this load time every time I want to look at which files are loaded. Thanks!
Originally posted by mason
Hi Fusoya,
First off, I'd like to thank you for all your work over the years on LM.


Thanks. #ab{:)}

Originally posted by mason
My question is related to the opening of the Super GFX Bypass menu. I think it's on all of the GFX file-related menus, actually. I noticed that, ever since I upgraded to Windows 11, those menus have taken forever to open up. Of course I'm spoiled, but it's still about 4-5 seconds every time, compared to all other menus taking a fraction of a second at the most. I thought initially that this would be related to the addition of the GFX file edit buttons in 3.30, but it still happens on older versions. I was curious to see if you had any thoughts about the cause of it for this window only, or if you think there's anything I can do on my side to reduce this load time every time I want to look at which files are loaded. Thanks!


Windows 11 again, hmm? Check a few posts above for someone that had a similar problem.

Given what he experienced, if you're willing to experiment you might want to try temporarily turning off some of the security extras in Windows 11 one by one to see if you can isolate what's killing your machine's performance. Smart App Control, core isolation, memory integrity, maybe even Windows Defender. Unless you have a third party virus scanner, in which case you might want to disable that first to see if there's any change.

But as a last resort, in LM you can go to "Options", "General Options", and uncheck "Standard GFX Bypass Dialogs". That will cause LM to use a more light-weight version of those windows where it uses plain edit controls instead of creating those large combobox lists. I've still kept it around for really slow (20+ year old) computers, or for those that want to use common controls version 6 for visual styles/themes in LM (as that themeable version of Microsoft's built-in controls is much slower to work with, which is especially noticeable when you're dealing with large lists).


Also, just in case... do the buttons in LM's main toolbar look flat, or like proper buttons in the screenshots here?
Thanks for over many years of Lunar Magic

Now, something that still bothers me to this day, is that the palette editor could be better, like choosing to select direct HEX, as the RGB method is starting to look very antique for me. You can, I dunno, use some code from Palette Editor to incorporate it?


Have a frost day~
Originally posted by FuSoYa
Given what he experienced, if you're willing to experiment you might want to try temporarily turning off some of the security extras in Windows 11 one by one to see if you can isolate what's killing your machine's performance. Smart App Control, core isolation, memory integrity, maybe even Windows Defender. Unless you have a third party virus scanner, in which case you might want to disable that first to see if there's any change.

I disabled all of those that you listed -- and some others, for good measure -- and it still took a while.

Originally posted by FuSoYa
Also, just in case... do the buttons in LM's main toolbar look flat, or like proper buttons in the screenshots here?

They do look like the buttons in those screenshots, with the shadows and whatnot.

Originally posted by FuSoYa
But as a last resort, in LM you can go to "Options", "General Options", and uncheck "Standard GFX Bypass Dialogs".

This did shorten the wait time. Thanks for continuing to provide this view, I think it'll work well enough for me. I'll maybe keep experimenting down the road to figure out if there's anything I can do to make the newer menu load faster. Would be nice to have the drop-downs, but not the end of the world. It's a bit odd, I haven't really done anything to my Windows installation at all. I don't have anything unnecessary running in the background either. 6% CPU spiking to 15% when opening the drop-downed menu and then back down.
Originally posted by mason
I disabled all of those that you listed -- and some others, for good measure -- and it still took a while.


I wonder what else has been put in Win11 that could slow things down. I know Microsoft has been trying to limit Windows 11 to more recent CPUs, though you wouldn't think it would make that much of a difference. There are also rumors of them rewriting core libraries in Rust, including Win32 GDI. That was supposed to be initially disabled behind a flag, but they could be doing a controlled rollout for some...

Originally posted by mason
They do look like the buttons in those screenshots, with the shadows and whatnot.


Alright, guess we can rule out Microsoft forcing common controls v6 on some people. That would have been strange, but it was best to be sure.

Originally posted by mason
This did shorten the wait time. Thanks for continuing to provide this view, I think it'll work well enough for me. I'll maybe keep experimenting down the road to figure out if there's anything I can do to make the newer menu load faster. Would be nice to have the drop-downs, but not the end of the world. It's a bit odd, I haven't really done anything to my Windows installation at all. I don't have anything unnecessary running in the background either. 6% CPU spiking to 15% when opening the drop-downed menu and then back down.


Well, if you discover what's doing it then let me know. It would be nice to have a solution for it in case it happens to a few more people.

But it did occur to me Friday that it might be possible to improve performance in the standard GFX dialogs by doing some slightly crazy UI sleight of hand. #ab{;)} So I spent yesterday afternoon doing some experimenting of my own, and after some tweaking it looks like it should work. Wait time should be reduced by up to 80% on much slower systems. Think I'll do some more testing over the next couple of days to make sure no bugs come up before copying it to the rest of the GFX dialogs.

Originally posted by Blizzard Buffalo
Now, something that still bothers me to this day, is that the palette editor could be better, like choosing to select direct HEX, as the RGB method is starting to look very antique for me. You can, I dunno, use some code from Palette Editor to incorporate it?


Oh, I already added a small extra window a few months ago that lets you enter RGB hex values, in both PC and SNES format.
Originally posted by FuSoYa

But it did occur to me Friday that it might be possible to improve performance in the standard GFX dialogs by doing some slightly crazy UI sleight of hand. #ab{;)} So I spent yesterday afternoon doing some experimenting of my own, and after some tweaking it looks like it should work. Wait time should be reduced by up to 80% on much slower systems. Think I'll do some more testing over the next couple of days to make sure no bugs come up before copying it to the rest of the GFX dialogs.


Ooh, sweet! I appreciate you looking into it.
Hi again.
Sorry if this has already been mentioned, and it might be that I just haven't found the option for it yet, but it would be nice if there were a way to prevent the value of "Layer 1,2 (FG,BG) Initial Position" in the window "Modify Main and Midway Entrance (in hex)" from reverting back to its default value (FG= -70) whenever the player is moved around in the editor. Often when I'm trying to tweak things to get them to line up better, I'll want the camera to stay the same as I had it, just with Mario in a slightly different position. But when I make this change I have to go in and fix the camera settings back to what they were before, which also involves remembering what they were in the first place, or remembering to check before I move Mario.

If there's a way to prevent this in current version of LM, my apologies. If not, I'd strongly advocate for it. Thanks.
  • Pages:
  • 1
  • 2
  • 3
  • 4
  • 5
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70

Tool