It would be great if we could have a feature to view Layer Object Volumes through something similar to the tile outlines. Simply putting a square shape around extended map16 objects or the base game objects would help a ton with level size optimization.
It seems one of Lunar Magic's ExAnimation routines has a bug where it doesn't disable NMI during changing the D register, so when NMI fires during it, it quickly produces a crash.
Edit 2: I screwed up the values for the DMA transfer, that's why it took so long, and I forgot that routine was already in NMI, so disabling NMI would not get rid of that problem as it would fire as soon as it was enabled again and would result in a NMI in a NMI, which would be very bad anyway.
To turn this post into something more constructive, I should have mentioned I was trying to disable ExAnimations programatically... I think it should be more straightforward and documented in Lunar Magic help files. At first I was thinking I should store #$FF to $7FC00A. Then someone suggested to store #$000000 to $7FC000. Only storing $0000 to $7FC0C0, $7FC0C7, $7FC0CE.. etc. did the job.
I have been also wondering why $7FC003 didn't disable the ExAnimations since $14 was frozen.
It would be great if we could have a feature to view Layer Object Volumes through something similar to the tile outlines. Simply putting a square shape around extended map16 objects or the base game objects would help a ton with level size optimization.
Not all objects are rectangular (slopes for example). In any case, you can always select an object or group of objects to see which tiles belong to it/them.
Originally posted by Disk Poppy
To turn this post into something more constructive, I should have mentioned I was trying to disable ExAnimations programatically... I think it should be more straightforward and documented in Lunar Magic help files.
It's not documented because it's not supported or even really designed for it. There aren't too many cases where one would want to disable all ExAnimations in the middle of the level/overworld after you've already let them run.
Originally posted by Disk Poppy
I have been also wondering why $7FC003 didn't disable the ExAnimations since $14 was frozen.
If it ran, then it wasn't really frozen compared to the last frame. ExAnimation just keeps that copy of $14, and if the copy is different from $14 then the animations for the frame will be run and $14 is recopied.
There aren't too many cases where one would want to disable all ExAnimations in the middle of the level/overworld after you've already let them run.
The use case I ran into was having a custom gamemode accessed from the overworld (a stats screen) - the ExAnimations still ran while in the other gamemode.
Anyway, I found out that when repointing multiple levels' pointers to the same layer 1/2/sprite data, but only when repointing them outside banks $06, $07 (as the original game did so in these banks), Lunar Magic freaks out - on saving any level the banks in the pointers are changed resulting in garbage data in all the levels (the lower 16-bits appear unchanged in the pointers).
Anyway, I found out that when repointing multiple levels' pointers to the same layer 1/2/sprite data, but only when repointing them outside banks $06, $07 (as the original game did so in these banks), Lunar Magic freaks out - on saving any level the banks in the pointers are changed resulting in garbage data in all the levels (the lower 16-bits appear unchanged in the pointers).
Most likely you're somehow triggering re-initialization/installing of one or more ASM hacks that deal with SMW's original limitations on pointers. Remember the original game doesn't supply separate bank bytes for the sprite pointers, and the bank bytes for layer 2 data were only valid for when you had a level on layer 2 (for BGs the bank byte was originally just a placeholder of FF).
Though it's not really safe to have multiple levels pointing to the same data in the expanded area of the ROM anyway. Officially it's not supported by LM.
Unofficially though, it looks like LM might check for it only if the data isn't protected by a RAT... I probably threw it in as a favor for someone back in the Acmlm board days and forgot about it. But it's part of very old code that verifies level size from back before I came up with the idea of RATs, so it probably doesn't check newer things like ExAnimated pointers.
; Default sprite memory setting. If you're using No Sprite Tile Limits, you may want to set this to 10.
!SprMem = $10
padbyte $00
org $05E000
rep 512 : autoclean dl Layer12 ; repoint all Layer 1 pointers
rep 512 : dl Layer12 ; repoint all Layer 2 pointers
SprPointersLow:
rep 512 : dw Sprites ; repoint all sprite pointers
pad $05FFFF ; clear all data in tables $05F000-$05FFFF
org $0EF100
SprPointersHigh:
rep 512 : db Sprites>>16
org $0EF310
rep 512 : db %00000100
org $05DA17
JMP $DAD7 ; skip past the No Yoshi handler
org $05D766
rep 6 : dl Layer12 ; repoint No Yoshi intro Layer 1 pointers
rep 6 : dl Layer12 ; repoint No Yoshi intro Layer 2 pointers
freedata : print "Blank: ", pc
Layer12:
db $00,$01,$00,$00,$00,$FF ; blank data for layer 1/2
Sprites:
db !SprMem,$FF ; blank data for sprites
It's applied after modifying a level in Lunar Magic (and optionally cleaning the modified the level via another patch). As you can see it repoints the Lunar Magic's sprite banks too and makes the layer 2 use level data.
It also triggers the modification at $00F2DB (which was unwanted because another patch hijacked it) and probably other things.
Which brings me up to the third suggestion, but I don't know how feasible it is. Namely a LM's ASM hacks/hijacks menu that per every one of them has:
- A button to apply it now.
- A checkbox to prevent from applying it - any operation that would end up with applying it (like for example moving via dragging a Level Entrance) would end up being cancelled.
Maybe even an optional auxiliary file that would track the ASM hacks, so LM doesn't have to read from the ROM, if the ROM was changed in confusing ways to it.
It's applied after modifying a level in Lunar Magic (and optionally cleaning the modified the level via another patch). As you can see it repoints the Lunar Magic's sprite banks too and makes the layer 2 use level data.
I don't think you should turn on the new BG format flag for something that's not a BG, but otherwise... *shrugs* Nothing stands out, other than the hijack conflict that you're already aware of. If I had to hazard a guess, I'd say you're probably modifying or overwriting one of LM's ASM patches or hijacks with one of your other patches. Which as I said could trigger a reinstall or an upgrade.
Check the hijack map. And avoid supposedly "empty" areas in the original non-expanded ROM space, as those tend to get used by tables/ASM hacks and usually won't be in that map as they're not hijacking existing code there.
(Also if you're going to repoint the levels like that, I'd suggest overwriting one of the levels in the original ROM space with your empty level instead of storing it in the expanded ROM. That way you won't end up with pointers that point to data that doesn't exist anymore when LM saves a level and deletes the old one in the expanded ROM).
Originally posted by Disk Poppy
It also triggers the modification at $00F2DB (which was unwanted because another patch hijacked it) and probably other things.
Then... be careful not to do that? Look before you leap, and check your jump points in the hijack map on the site to see if you're going to be in conflict with LM or some other major tool/patch. Otherwise I'm afraid you're just going to keep creating problems for yourself.
Originally posted by Disk Poppy
Which brings me up to the third suggestion, but I don't know how feasible it is. Namely a LM's ASM hacks/hijacks menu that per every one of them has:
- A button to apply it now.
- A checkbox to prevent from applying it - any operation that would end up with applying it (like for example moving via dragging a Level Entrance) would end up being cancelled.
Maybe even an optional auxiliary file that would track the ASM hacks, so LM doesn't have to read from the ROM, if the ROM was changed in confusing ways to it.
Too much work, and frankly it'd be silly in a lot of cases. Quite a few basic things people take for granted are due to ASM hacks that LM installs. You don't want LM to say, install the ASM hack responsible for allowing you to place your levels in any order on the overworld? Well, ok then... I guess LM can't save a fair chunk of the overworld anymore since now there's no ASM hack to save the pointer into for data which happens to be in a format that the original game doesn't get anyway.
Thing is you don't necessarily know which ASM hacks rely on each other, which ones may be implementing which features, which ones implement features LM requires just for normal functioning, or which ones are checked to update data and other ASM hacks from 21 years worth of older versions of LM. Those checkboxes and buttons would just create the illusion of LM supporting something that it really doesn't.
Because as I've said many times before, modifying LM's ASM hacks and hijacks is not supported. Yes you can poke at them if you really want or need to... I occasionally even help people to do so when asked. But you do so with the full knowledge that you're taking your life into your own hands, that you're often making your hack fragile (especially if LM is updated) and that it's not my problem if you go and burn down your hack or your house doing that.
Final Theory
Posts: 1770/1777
Since:
Location: The Milky Way Galaxy
Last seen: 22 hours, 33 minutes and 24 seconds ago
I'm not sure if this is a bug, but I've encountered something weird in Lunar Magic. I followed this tutorial and this tutorial and have both Lunar Magic's 2BPP Mode and Layer 3 16x16 tile 1,024 x 1,024 tile map setting on for this sublevel, and there is this weird set of blank tiles on the bottom of the editor. They don't seem to be a part of Layer 1, 2, or 3. I think it might be a display issue with Layer 3 because if I put Layer 3 tiles in those areas, they get filled in in the Layer 3 tile map editor but not the main level editor and everything does show up correctly in the game. What is going on? What is with those blank tiles?
Click the character on the right side of my layout to visit my Discord server and discuss and play and look at and get updates and sneak peeks of the games and other things I'm making.
Okay so I just got done beating Final Fantasy II (USA) or actually Final Fantasy 4 (Japan).
So now I have some deep insights on FuSoYa and Lunar Magic. Here they are:
Lunar Magic was originally a Sailor Moon editor. Hence Moon theme.
Lunar Magic uses a Moon as its icon. It just so happens that there is a Moon in Super Mario World.
FuSoYa is a character from FFII and he is from the Moon.
Do you see? It's all Moon related. Like the creator of Lunar Magic and Lunar Magic itself. It all has a Moon theme.
But you would only know and understand this if you beat Final Fantasy II and just today in 2022 I finally beat this game.
Oh, nice to see people are still playing that one for the first time. FF2 is probably the first RPG I ever played.
And yes, it's all moon related.
Originally posted by DPBOX
I'm not sure if this is a bug, but I've encountered something weird in Lunar Magic. I followed this tutorial and this tutorial and have both Lunar Magic's 2BPP Mode and Layer 3 16x16 tile 1,024 x 1,024 tile map setting on for this sublevel, and there is this weird set of blank tiles on the bottom of the editor. They don't seem to be a part of Layer 1, 2, or 3. I think it might be a display issue with Layer 3 because if I put Layer 3 tiles in those areas, they get filled in in the Layer 3 tile map editor but not the main level editor and everything does show up correctly in the game. What is going on? What is with those blank tiles?
Yes, looks like it's a bug. The editor just isn't drawing those tiles... it's triggering a range check that's not supposed to apply to that mode. I guess no one noticed before since it's an unofficial mode in LM that few people even know about let alone use. But thanks, I've got it fixed now for the next version.
What is the difference between 2BPP Modes 1 and 2, anyway? I can't find anything about 2BPP Mode or Layer 3 16x16 Tile Mode in the help file anywhere.
Also, that issue I reported above seems to have mysteriously went away.
Click the character on the right side of my layout to visit my Discord server and discuss and play and look at and get updates and sneak peeks of the games and other things I'm making.
What is the difference between 2BPP Modes 1 and 2, anyway? I can't find anything about 2BPP Mode or Layer 3 16x16 Tile Mode in the help file anywhere.
It's described here. Unofficial features like those normally aren't in the help file since technically they're not supported... they're usually just little extras I've thrown in for someone. Which means they could get removed/modified or stop working at some point, but more often they're simply forgotten about.
Originally posted by DPBOX
Also, that issue I reported above seems to have mysteriously went away.
Most likely it was just masked by changing the background color or something.
I noticed when using the "View bottom row of tiles" option is used in a level the position will be delayed in game like seen in the GIF below.
However, this gets fixed as soon as you change the player positions by moving him up/down as LM probably doesn't adjust the positions automatically when that option is turned on.
Would be nice to do so since it could lead to confusion about this option not working properly.
Regarding sprite extra byte sizes:
Would you consider a minor extension to the current system to allow using the same size for all sprites of a given ID?
To quote the manual...
Originally posted by LM Help File
(first 0x100 bytes are for sprites 00-FF that use an extra bit of 0, next 0x100 are for sprites 00-FF that use an extra bit of 1, etc)...Then put 0x42 at 0x7750F to enable use of the table by Lunar Magic
Would you consider allowing to write an alternate value to PC 0x7750F to have the editor use a single size for each sprite of a given id (instead of 4), to allow using a table a quarter of the size?
It's somewhat minor and for a sprite tool I'm working on personally, but it would be nice to have regardless.
Thanks for your consideration.
Eh, no I don't think so. Since LM3 the table is now also read by ExLevels, which means ASM changes to support that. Not really worth it for just 0x300 bytes.
If you don't plan to have different sizes for different extra bits, you can always just set the extra entries in the table to the same values as for extra bit 0.
Major thanks to Nenilein (a.k.a. @PinkGeekNeni on Twitter) for the profile pic I'm using!Help us raise funds for the Armed Forces of Ukraine. #ДопомагаємоРазом / #HelpTogether “Even if you personally are so dissatisfied with life that you want the world to end, surely the cruel reality is that it will continue on, unchanging. All the better for someone perfectly content, like me.”
– Aya Shameimaru, Touhou Suzunaan ~ Forbidden Scrollery
Yup, like the help file says they appear above sprites (which would include entrances). For something like that I wanted them highly visible so you wouldn't have to turn off sprites to find hidden ones behind them.
Follow Us On