Language…
8 users online:  Ayami, Darknubs, Falconpunch, h.carrell, Isikoro, neidoodle, QuantumNate, spratt - Guests: 67 - Bots: 180
Users: 58,128 (2,470 active)
Latest user: maczampieri

Lunar Magic suggestions and discussion (LM v2.52)

Link Thread Closed
  • Pages:
  • 1
  • 2
  • 3
  • 4
  • 5
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
Originally posted by RenkoV2
This has probably been asked before, but is there a way for you to extend the size of the OW and/or add an extra submap? if thats even possible lol

Nope, but JUMP did have an extra submap, and it was pretty hacky too.
Hi, I'm a signature!
Hack Thread
Hack Testing Status: Available.
Layout by Koopster.
Not sure if this got suggested already but with the sprite remoderation and use of PIXI which supports the extra property bytes, would it be worth the add a feature to the .ssc file or something to label the extra property bytes in LM?

Also, I think it'd be better to have it editable in 4 8-bit numbers rather than 1 32-bit number since they are stored in ram as 4 separate 8-bit numbers as well and pretty much never used as more than that.


edit:

I'm not sure what's going on here. Is this a bug with vertical levels and extra bytes in LM?
(The numbers in the status bar are the extra bytes 1, 2, 3 & 4, in horizontal levels it's just as it's supposed to be but in vertical levels it shows completely different values for some reason)
Originally posted by Fostelif
Can you add something to the tooltip/sprite list title for sprite F4 (fast BG scroll) so that it also says you can use sprite 5E to activate it?


Alright

Originally posted by TheBiob
Not sure if this got suggested already but with the sprite remoderation and use of PIXI which supports the extra property bytes, would it be worth the add a feature to the .ssc file or something to label the extra property bytes in LM?


I believe it already displays the bytes themselves in the tooltips (or in "View Sprite Data" when there's just 1), which should be good enough for now.

Originally posted by TheBiob
Also, I think it'd be better to have it editable in 4 8-bit numbers rather than 1 32-bit number since they are stored in ram as 4 separate 8-bit numbers as well and pretty much never used as more than that.


Doesn't make much difference, but the current method is still more flexible if the number of bytes changes.

Originally posted by TheBiob
I'm not sure what's going on here. Is this a bug with vertical levels and extra bytes in LM?


If it's only in the game, then no. LM doesn't insert any ASM at all for parsing and storing sprite extra bytes. That's up to third party patches to do.
Am I the only one who has noticed that FuSoYa released a new version of Lunar Magic yesterday? Because he did (Happy 17th anniversary of LM's release, by the way). The support for custom overworld sprites, the additional FG/BG map16 pages, and the additional Secondary Entrances are all very nice additions! I don't have much use for these features currently (aside from one), but I'm sure others will appreciate them, especially those working on collab hacks.

Funnily enough, I actually wrote some code not that long ago that would allow me to have 1024 secondary entrances for something specific I was working on. However, I did it by putting a JML at $05D7D9 that would allow me to add a check for whether to use the original SE tables or an alternate set. Your way of implementing this was better, though.


Also, I have a major bug to report. It seems that the 8x8 editor in the map16 editor is broken, as doing most things with it causes Lunar Magic to crash.

Edit: I've taken the liberty of submitting a few of the new Lunar Magic hijacks to the hijack map. Because my hack is set up like a giant ASM patch, I needed to disassemble the new ASM code in order to be able to use the new features, so I figured I might as well contribute to the hijack map a little. However, I only submitted the ones that I knew exactly what they were doing, so there are a couple I didn't submit.
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 (7/8/2022 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
It seems that the 8x8 editor in the map16 editor is broken, as doing most things with it causes Lunar Magic to crash.


I confirm that.
Layout by Koopster
I was constantly refreshing fusoya's website waiting for an hypothetical update but gave up and went to sleep. I'm pleasantly surprised.
Great to see the better kind of Overworld Sprites support. Guess I finally have to convert them all into non-SA1 😅
Thanks for the update #smw{:TUP:}
Wow...
The new version of Lunar Magic is awesome.
More space for the BG & FG tiles.
But i wanted to ask to Fusoya if he'll implement the BG4 and BG5 space graphics in the future versions of Lunar Magic.

Fusoya is becoming a god.
Originally posted by Roberto zampari
But i wanted to ask to Fusoya if he'll implement the BG4 and BG5 space graphics in the future versions of Lunar Magic.

That will be difficult. For one, he needs to free up 8KiB which is a rather difficult task since 24KB already. The SNES has got 64KiB of VRAM of which 24KiB goes to layer 1 and 2 GFX, 8KiB for layer 1 and 2 tilemap, 8KiB for layer 3 GFX, another 8KiB for layer 3 tilemap, and finally 16KiB for sprite GFX.
There used to be a patch which allows you to insert even four more GFX slots at the expense of layer 3 (two and a bit of its tilemap for two slots and altogether for four slots).
There is no way he can just add two more layer 1 and 2 ExGFX slots without sacrifising layer 3 or other stuff.
I mean, of course, he theoretically can do it but there also is the problem that users won't understand the layer 3 sacrifice which makes it rather unlikely.
Originally posted by MarioFanGamer
Originally posted by Roberto zampari
But i wanted to ask to Fusoya if he'll implement the BG4 and BG5 space graphics in the future versions of Lunar Magic.

That will be difficult. For one, he needs to free up 8KiB which is a rather difficult task since 24KB already. The SNES has got 64KiB of VRAM of which 24KiB goes to layer 1 and 2 GFX, 8KiB for layer 1 and 2 tilemap, 8KiB for layer 3 GFX, another 8KiB for layer 3 tilemap, and finally 16KiB for sprite GFX.
There used to be a patch which allows you to insert even four more GFX slots at the expense of layer 3 (two and a bit of its tilemap for two slots and altogether for four slots).
There is no way he can just add two more layer 1 and 2 ExGFX slots without sacrifising layer 3 or other stuff.
I mean, of course, he theoretically can do it but there also is the problem that users won't understand the layer 3 sacrifice which makes it rather unlikely.

Yeah, it may be dificult, Fusoya will find a way somehow.
He stated that will find a way to fix the 4000-7FFF space for FG.
Now i ask you, where came the bizarre idea to add more space for BG&FG tilesets?
Originally posted by MarioFanGamer
Originally posted by Roberto zampari
But i wanted to ask to Fusoya if he'll implement the BG4 and BG5 space graphics in the future versions of Lunar Magic.

That will be difficult. For one, he needs to free up 8KiB which is a rather difficult task since 24KB already. The SNES has got 64KiB of VRAM of which 24KiB goes to layer 1 and 2 GFX, 8KiB for layer 1 and 2 tilemap, 8KiB for layer 3 GFX, another 8KiB for layer 3 tilemap, and finally 16KiB for sprite GFX.
There used to be a patch which allows you to insert even four more GFX slots at the expense of layer 3 (two and a bit of its tilemap for two slots and altogether for four slots).
There is no way he can just add two more layer 1 and 2 ExGFX slots without sacrifising layer 3 or other stuff.
I mean, of course, he theoretically can do it but there also is the problem that users won't understand the layer 3 sacrifice which makes it rather unlikely.

easiest thing would be to use SP3/4 since you dont have to do much vram rearrangement in that case (just repoint the l1 chr)
Originally posted by yoshifanatic
Also, I have a major bug to report. It seems that the 8x8 editor in the map16 editor is broken, as doing most things with it causes Lunar Magic to crash.


Seems there's so much Map16 data now, one of the functions blew the stack... anyway thanks, 2.51 is up now.
Originally posted by Ladida
easiest thing would be to use SP3/4 since you dont have to do much vram rearrangement in that case (just repoint the l1 chr)

...and relying on it wrapping?

...that's ... crazy enough to work. but there's a pretty good chance one of the emus don't support that (hopefully zsnes)

Either way, someone would have to increment the TT bits on EVERY SINGLE level tile, including changing blocks, including all custom blocks (luckily, most of them use shared routines for that these days).

And you must either leave the OW tiles and credits alone, or convert them too.

Have fun.

It's a good idea in theory, but I don't think it's realistic. And rewriting all the L1 tiles is probably the same amount of effort as rearranging VRAM, anyways.

But on the other hand, I considered SuperFX unrealistic as well. Feel free to prove me wrong.
<blm> zsnes users are the flatearthers of emulation
Personally, I'd just like to have a setting somewhere for entirely customizable VRAM layouts (probably hidden so it doesn't confuse newbies, but documented). SMW doesn't even have mirrors for most of the VRAM-related addresses.

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

I'm working on a hack! Check it out here.
yeah thinking about it itd be much easier to just move the l1/2 maps when you want bg4/5, so bg4/5 just go at $3000 like they would normally and l1/2map go wherever (i would put at sp3/4 but thats because i love layer 3 and hate sprites)
I found a bug with map16 in the 2.51 version:
If I change any of the tiles in page 2 of the map16 editor, and then save the map16, every tile from page 2 starts acting like every tile from page 1.
Originally posted by Christian07
I found a bug with map16 in the 2.51 version:
If I change any of the tiles in page 2 of the map16 editor, and then save the map16, every tile from page 2 starts acting like every tile from page 1.


Appears to be working fine for me. Both from upgrading and from a fresh ROM.
I tested it myself too, and it works as intended. Normally I don't use Page 2 though.

While I'm here, I noticed the position of the submap ghost in slots other than the last three actually isn't random. It's actually the corresponding submap position of where its main map counterpart appears in the editor, however, it gets stuck on that one point and simply turns back and forth.

Also, probably more a LMSW bug, but Conditional DirectMap16 is always on in LMSW. Maybe I'm just using an outdated version, I dunno.
Let's milk Sunny Milk. Then she'll have enough money to fund Sunny Milk Real Estate.
Everypony's digging with a shovel
Originally posted by FuSoYa

Appears to be working fine for me. Both from upgrading and from a fresh ROM.

Have you tried testing it in ROMs with the SA-1 patch? It first happened with a hack that had that patch.
Also, I've tested it now and it seems to happen only if the ROM has the SA-1 patch and the map16 was first saved with the 2.43 version.
Originally posted by Wiimeiser
Also, probably more a LMSW bug, but Conditional DirectMap16 is always on in LMSW. Maybe I'm just using an outdated version, I dunno.


In the view menu you can turn off "Other Invisible Objects" and "Conditional Direct Map16 On" to turn them all off. Probably not ideal if you want to test cases with only some of them on though.

Originally posted by Christian07
Also, I've tested it now and it seems to happen only if the ROM has the SA-1 patch and the map16 was first saved with the 2.43 version.


Ah ok, looks like the upgrade code for Map16 neglects to do SA-1 adjustments. In a day or two you'll be able to just resave the Map16 in version 2.52 to fix it.
Here's something I found in the latest version:
In Modify Main and Midway Entrance(in hex), layer 1,2 FG/BG Initial Positions, there's FG=CF at the first option, instead of FG=C0.
  • Pages:
  • 1
  • 2
  • 3
  • 4
  • 5
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
Link Thread Closed