Language…
6 users online: Dan2point5, fsvgm777, JeepySol, JPhanto, kirsvantas, random_box - Guests: 259 - Bots: 277
Users: 64,795 (2,377 active)
Latest user: mathew

LMSW: An emulator inside Lunar Magic

Originally posted by Ayosuf
Also, what do you guys think: should LM automatically leave sprite editing mode when starting the internal emulator? I did notice a few times that it was a bit annoying to start it, have nothing happen, and then remember "oh yeah, still in sprite editing mode..."

Why not just allow it to remain running while in sprite editing mode?

–=–=–=–=–=–=–
Advynia: a Yoshi's Island editor - Alyssa's Unlikely Trap demo 3
Originally posted by TRS
When I bring up the emulator, either it or LM is slightly corrupting some of my coin ExAnimation graphics for some reason.

Doesn't appear for me with the original animations, and I'm too lazy to figure out how the new exanimation system works. Could you give me an IPS?

Originally posted by Zeldara109
Why not just allow it to remain running while in sprite editing mode?

Sprite editing mode means sprites are moveable.
If LMSW remained running in sprite editing mode, people would expect the sprites in LMSW to move as well.
I can not perform that operation; I'm pretty sure LM can reorder the sprites in its lists, so I can't use that method to connect a sprite in LMSW with a sprite in the ROM. Additionally, some sprites change behaviour when moved (for example green bouncing Koopas). The only solution I saw was reloading them every time, and that's a poor idea to do too often.
<blm> zsnes users are the flatearthers of emulation
Originally posted by Alcaro
Originally posted by TRS
When I bring up the emulator, either it or LM is slightly corrupting some of my coin ExAnimation graphics for some reason.

Doesn't appear for me with the original animations, and I'm too lazy to figure out how the new exanimation system works. Could you give me an IPS?


Here you go. The level in the video is 108, but it happens in a few other levels as well.
Verified fixed. Looks like I wrote to a null pointer, indexed by a couple of millions. I don't think that write is needed anyways.
Have fun.
<blm> zsnes users are the flatearthers of emulation
SMW’s original exits that lead to any level < 100 get messed up.

For example, when I’m in level 23 and go through the pipe exit to D7, I go to level 1D7 instead. When I actually switch to level D7 and go through the secondary exit back to level 23, I go to level 100 instead.
When I’m in level 10 and take the pipe to level C1, I go to level 1C1 instead. When in level C1 and I take the secondary exit back to level 10, I go to level 11F instead.

However, it only seems to affect SMW’s original exits. When I place an exit to level 10 in any level (regardless of whether < 100 or > 100) it always leads to level 10.
GradientToolLevelMusic UtilitySM64 Clean ROM verifierHQX VirtualDub FilterImoSPC2 (Alpha)Music Section SPC PlayerEmbeddable SPC Player for SMWCYouTube EmbedderJSRomcleanJS Address ConverterLazyHDMA
----------------

Originally posted by ShadowFan-X
*text*


Same happens to me, as far as I can tell it will always do that till you edit the level and save it, then it'll go to the proper sublevel


----------------
Red Tales: Part 1: Hack is being worked on. Committed to finishing this time
Levels Complete: 6/29 Exits: 16/40
...eh, whoops. I set that variable at wrong place.
I'll fix it in the next release. Since it only affects unedited levels, I don't consider it very important.
<blm> zsnes users are the flatearthers of emulation
Originally posted by Alcaro
I'm pretty sure LM can reorder the sprites in its lists, so I can't use that method to connect a sprite in LMSW with a sprite in the ROM.


Well, there is a solution for that bit. LM would have to assign each sprite in the list a unique ID, and supply the ID list to the DLL along with the regular sprite level list. Then when something is changed, LM would supply both lists again and it'd be possible for the DLL to compare the current ID list against the previous list to work out which sprite has gone where in the main sprite list (missing ID=sprite deleted, new ID=new sprite, matching ID=can compare to sprite from previous list to check changes).

There's still the changing behavior though.


But anyway, I think the current "pause to edit sprites, then reinit them when done" method works pretty well.
It's an interesting idea, but it doesn't solve the problem with sprites changing behaviour if moved. Reloading only one sprite would desync them and make the ASM codes more annoying.
Another problem is that LMSW usually isn't transparent, which makes it hard to find any sprites behind the LMSW window. Since LMSW is what it is, all sprites you're likely to want to poke at are in exactly that blind spot.
<blm> zsnes users are the flatearthers of emulation
I know it's possible for there to be sprites that weren't there when the level loaded (anything that comes from a generator, or from another sprite like Lakitu's spinies)...

Is it possible for any sprites currently in one of the twelve sprite slots to remain in place (and be treated as if they were from a generator), and any sprites that would appear on-screen not be loaded when you resume? I know that could result in duplicate sprites (and force you to scroll any newly placed sprites off-screen before they'll appear), but it's better than sprites spontaneously warping on top of you or to the other side of the level, in my opinion.

–=–=–=–=–=–=–
Advynia: a Yoshi's Island editor - Alyssa's Unlikely Trap demo 3
Sure, why not? Have fun.
Technical information for FuSoYa: I also added EXPORT int LMSW_ApiVersion() { return 1; } to this version of LMSW. The point of this should be obvious.
<blm> zsnes users are the flatearthers of emulation
Would it be feasible to add a feature which could teleport Mario to an arbitrary location in the level? It would certainly be useful when testing a specific area of a long, difficult level.
GradientToolLevelMusic UtilitySM64 Clean ROM verifierHQX VirtualDub FilterImoSPC2 (Alpha)Music Section SPC PlayerEmbeddable SPC Player for SMWCYouTube EmbedderJSRomcleanJS Address ConverterLazyHDMA
Mario has been movable since LM 1.63, and probably even longer. Just remember to save before opening LMSW (a limit in our communication).
If you want Mario movable with the mouse, it's on FuSoYa's to-do list. I can't do anything about it.
<blm> zsnes users are the flatearthers of emulation
This will help me out sooo much I'm just sad it has no game-pad support, but I hope that will be fixed in the future!
Finally updated it (I had the first release all this time :3)
The speed is amazing now, so it's finally useful to me thank you! x
Why does every time a muncher appear when I turn on the emulator from LM?
Originally posted by Bistai949
I'm just sad it has no game-pad support

Wow, that's a lot of babble about gamepads.
I don't have any gamepads, and I'd prefer not releasing untested code. Just use joy2key.

Originally posted by iRhyiku
The speed is amazing now,

Yeah, snes9x is faster than bsnes, and with all the RAM pokery I'm doing, I saw no valid reason to promote emulator accuracy in this context.

Originally posted by Ripperon-X
Why does every time a muncher appear when I turn on the emulator from LM?

floating muncheeeeers~

It's controlled by the :) switch in lmsw.cfg. It won't get saved to anywhere.
<blm> zsnes users are the flatearthers of emulation