Language…
12 users online:  AmperSam, CroNo, DanMario24YT, fsvgm777, Guido_Keller, Isikoro, JezJitzu, Sweetdude, timothy726, tOaO, Tomi P, Zavok - Guests: 269 - Bots: 357
Users: 64,795 (2,377 active)
Latest user: mathew

Lunar Magic suggestions and discussion (LM v3.40)

Tool

Ooh, being able to have more than one secret exit in a level is pretty sweet. I noticed that while extra goal tape sprites were added in to accommodate this, the same wasn't done for keyholes. Any reason as to why? Just seems weird to have one but not the other.

Originally posted by LucasRCD
Suggestion: An option that's similar to Ctrl + Del (removes everything inside of a level), but it affects all levels in one go. I don't know if this has been suggested in the past, but I feel like this would be at the very least convenient for people who want to start a new hack with all levels being "clean".

In case this has already been suggested in the past and you rejected it before, then... just pretend I never made this post.


Not a bad suggestion, though I would add a "blacklist" of certain levels so they can't be deleted that way (namely the title screen level, intro level, Yoshi's House, boss rooms, and bonus game).
I was tinkering with level 105 for an unrelated reason, and it seems like Lunar Magic isn't properly deleting objects that spawn tiles outside the new level boundaries when you change the size of a level. Attempting to save 105 after I changed only the level size and nothing else gives me an error that says "There is at least 1 object that is placing tiles beyond the bottom or right side of the last screen in the level."

Reproduction steps:
Open level 105 on a clean ROM.
Change the horizontal level mode to one of A/B/C/E/F/10/12/13/14/15/16/17/18/19/1A/1B/1C.
Save.
Tides break in levels with modified dimensions; specifically the game seems to have the water at the top of the level and nowhere else. Layer 2 works fine, though. Probably a starting offset bug or something like that.

Also, probably more a bug in LMSW, but moving tiles within the internal emulator screen doesn't graphically update the game screen like it did in previous versions.
Let's milk Sunny Milk. Then she'll have enough money to fund Sunny Milk Real Estate.
Everypony's digging with a shovel
I only downloaded it an hour ago and I'm already so happy there is the "tile surface outline" option! Make slopes soooo much easier to make! That alone is a game changer (well, a "level design changer")

Thanks FuSoYa and all the person involved, and happy holidays to you all
Super Mario Pants World
Luigi's Lost Levels
New Super Mario Pants World
Luigi's Lost Levels 2 - Back With A Revenge
Luigi's Lost Levels 3 - Electrik Boogaloo
VLDC12 - 72HoKaizo#1
Wow, that's actually an amazing Christmas present. I always wanted to be able to modify dimensions in either vertical or horizontal levels, and the new features give us a lot of new possibilities. This just show how far ROM hacking has gone.
I cannot beat levels with goal tapes because nothing happens when I touch them, regardless of which tape, event and direction I set. Keys and goal orbs work fine. I know it's been reported in another thread, but I'm just logging it here

EDIT:
Yep, had to do with how the old PIXI code fucks up what was changed around the goal tapes. Damn.
Windowless ride, feeling alive
Are you alive or just breathing?
Anyone have issues with the Windows Smartscreen and the newest version of Lunar Magic (v3.0) ?
That was the reason why didn't opened.

Also, would we remoderate all the patches and UberASM over again due to the new version of Lunar Magic?

Oh hey, look what I made appear.
#ab{^^;;;} I guess now we know what those strings in the EXE are for.

The reason I found those is a bug I'd like to report: when the main LM window is maximized, the right edge of the inner window is visible (instead of a scrollbar, or the lack of one.)




Another thing that may or may not require attention: have layer 2 scroll commands been proven to work with the new level height system? Either there's still need for adjustment on FuSoYa's end, or I haven't yet grasped what settings they now need.

With a level layout like that in the screenshot (brown blocks on layer 2, everything else on layer 1), part of the foreground scrolls along with layer 2. When I move the sprite down one tile (i.e. range 05), layer 2 scrolls down considerably once before locking into the expected up-down pattern.

(I haven't changed any BG position or scroll settings from the defaults, mostly because I couldn't find any setting that makes the BG position not relative and doesn't kill the player.)


Originally posted by Roberto zampari
Anyone have issues with the Windows Smartscreen and the newest version of Lunar Magic (v3.0) ?
That was the reason why didn't opened.

New LM versions have always done that. To run the file, you can click on "more information" to bring up a "run anyway" button.

 


 
Originally posted by Noivern
I was tinkering with level 105 for an unrelated reason, and it seems like Lunar Magic isn't properly deleting objects that spawn tiles outside the new level boundaries when you change the size of a level. Attempting to save 105 after I changed only the level size and nothing else gives me an error that says "There is at least 1 object that is placing tiles beyond the bottom or right side of the last screen in the level."

Reproduction steps:
Open level 105 on a clean ROM.
Change the horizontal level mode to one of A/B/C/E/F/10/12/13/14/15/16/17/18/19/1A/1B/1C.
Save.


That's a thing I have noticed while testing the beta builds. When changing the level size it's usually recommended just hit Ctrl+Del and wipe all level data because not always LM will delete the objects outside the screen for you.

Check how many screens will be removed and remove the objects nearly them before changing, if you're already working on a level.

Originally posted by Wiimeiser
Tides break in levels with modified dimensions; specifically the game seems to have the water at the top of the level and nowhere else. Layer 2 works fine, though. Probably a starting offset bug or something like that.

Also, probably more a bug in LMSW, but moving tiles within the internal emulator screen doesn't graphically update the game screen like it did in previous versions.


Yeah, they will break. Tides are very code specific (enables layer 2 and puts water tiles on fixed positions then "simulates" behavior on the layer 3 instead), so they won't work with the extended level. After all, they don't even expect to the level have any vertical scrolling at all.

LMSW unfortunately as far I know it needs an update on its own and not on LM.

Originally posted by Romano338
I only downloaded it an hour ago and I'm already so happy there is the "tile surface outline" option! Make slopes soooo much easier to make! That alone is a game changer (well, a "level design changer")

Thanks FuSoYa and all the person involved, and happy holidays to you all


Thank you!

Originally posted by Katerpie
I cannot beat levels with goal tapes because nothing happens when I touch them, regardless of which tape, event and direction I set. Keys and goal orbs work fine. I know it's been reported in another thread, but I'm just logging it here

EDIT:
Yep, had to do with how the old PIXI code fucks up what was changed around the goal tapes. Damn.


Any goal tape issues is a problem on the Sprite Tool end, yeah.

Originally posted by Roberto zampari
Anyone have issues with the Windows Smartscreen and the newest version of Lunar Magic (v3.0) ?
That was the reason why didn't opened.


Windows Smartscreen's algorithm is simple

1) is it a signed tool = safe
2) is it a tool known already by the windows user spying system? = safe
3) is it a recently released tool? = virus

I recommend turning it off. It's useless.

Originally posted by Roberto zampari
Also, would we remoderate all the patches and UberASM over again due to the new version of Lunar Magic?


Never. Only three patches break with the new LM.
And the tools that would require updating were pretty obvious (SA-1 Pack and Sprite Tools).

LM 3.00 was made for keeping maximum compatibility possible. If it would require a remoderation I would not even have proposed to FuSoYa my ExLevel and ExSprites patches.

I'm gonna make a small explanation on how everything works soon. Technically there is not even much hijacks, more like remaps similar to SA-1 Pack.

A hijack makes a obstruction on the original code, includes opcode replacements. Invasive method.

Now a remap just changes the address parameter of an opcode. Non-invasive method.

The broken patches so far were because of a single hijack (against the earthquake algorithm) and RAM conflict ("unused used" memory) or because LM already implemented them now.

Originally posted by WhiteYoshiEgg

Oh hey, look what I made appear.
#ab{^^;;;} I guess now we know what those strings in the EXE are for.


Oh nice, I was suggesting a way to FuSoYa to divide the window somehow or leave an empty space or even some form of zooming out stuff. Close enough I guess.

As for the scrolling issue, I recommend carefully reading the help file about the Layer 2 scrolling settings. A lot of thing changed and it's indeed a bit confusing to get because it's way easier than can you imagine ^^
GitHub - Twitter - YouTube - SnesLab Discord
This big level hack is amazing, I thought it would be many years before we have a level editor capable of it. Thank you for the implementation.



YouTube Twitter Twitch
Pretty cool stuff. The new level size system gives me some incentives to do a Yoshi's Island-style hack or a Metroidvania hack like I've had in mind before, the overworld teleport option for secondary exits seems useful for warp zones among other things, and the new FG/BG init system should be easier to use than the old one.

I must ask, though...why is the minimum level height still 0x1B tiles? Making it shorter in order to make it longer horizontally could be useful, especially for Layer 2 levels. (Certainly more so than making it 38 subscreens tall...) And why is the overworld abbreviated as "OV" rather than "OW"?

Also, where is the technical documentation for taking the new features into account in custom code, if there is any? That makes a huge difference when coding sprites, objects, and probably a lot of other things. If it's in the help file, I certainly couldn't find it, not even the new RAM addresses used.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
The minimum is still 0x1B because that's the original height in the SMW game and reducing the height even more wouldn't increase the maximum limit of horizontal screens, due of RAM limitation. Making that surely would cause astronomical incompatibilities. If it wasn't for that, modes 0x1D ~ 0x1F would be the ones that allows up to 0x38~0x40 horizontal screens and maximum height of 0xE0~0x100 tiles.

Once again, still working on the documentation about how everything works.

The system is split in two parts, one for handling the level system (custom level sizes, fix for vertical level boundaries, table rebuilder, level remapper, horz fixes, etc.) and another for handling the sprite system (128 sprite support, new format for allowing vertical jump, vertical spawning, variable sub off screen, the sprite cacher/accelerator, smart sprite loader, automatic page increment for hybrid sprite loading, etc.).
GitHub - Twitter - YouTube - SnesLab Discord
Originally posted by Vitor Vilela
Never. Only three patches break with the new LM.
And the tools that would require updating were pretty obvious (SA-1 Pack and Sprite Tools).

LM 3.00 was made for keeping maximum compatibility possible. If it would require a remoderation I would not even have proposed to FuSoYa my ExLevel and ExSprites patches.

If this was true, then why THIS THREAD exists?
Originally posted by Vitor Vilela
The minimum is still 0x1B because that's the original height in the SMW game and reducing the height even more wouldn't increase the maximum limit of horizontal screens, due of RAM limitation.

RAM that isn't $7E/7FC800? If levels were only 16 tiles high, for instance, they could be 38 screens long and still fit in those tables. Is there another RAM address that doesn't go high enough?

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Originally posted by Roberto zampari
Originally posted by Vitor Vilela
Never. Only three patches break with the new LM.
And the tools that would require updating were pretty obvious (SA-1 Pack and Sprite Tools).

LM 3.00 was made for keeping maximum compatibility possible. If it would require a remoderation I would not even have proposed to FuSoYa my ExLevel and ExSprites patches.

If this was true, then why THIS THREAD exists?


Pure speculation. The amount of *unexpected* broken resources are extremely low. Much less compared to LUNAR MAGIC 1.70, for example, that had problems from custom music not working to complete level destroyation due of variety problems. Many of the problems so far are from people that forgot to either update SA-1 Pack or Sprite Tool.

Wall Kick was a problem on a rather bad hijack choice. Minimalist Status Bar a (very) bad free RAM choice (which isn't free RAM at all and the dynamic level patch reclaimed it). One or another problem reported does not cause any crash at all, just makes that specific resource not work with the extended level height, but still works normal with the normal level mode.

LM 3.00 was extremely tested and verified before being released, by two really competent ASM coders that knows what they're doing.

Still, problems can always occur. There's always a chance. But in case it happen, you can restore your ROM, you can report at us, you can double check for resource updates. The update is reliable and safe to use.

Originally posted by imamelia
Originally posted by Vitor Vilela
The minimum is still 0x1B because that's the original height in the SMW game and reducing the height even more wouldn't increase the maximum limit of horizontal screens, due of RAM limitation.

RAM that isn't $7E/7FC800? If levels were only 16 tiles high, for instance, they could be 38 screens long and still fit in those tables. Is there another RAM address that doesn't go high enough?


This version however moves the map16 indexing memory to the RAM, hence custom level sizes are possible. During level initialization the map16 tables are dynamically built per screen. If a screen is #$0300 tiles big, each screen is incremented by #$0300. $7E:C800, then $7E:CB00, $7E:CE00, etc., until all screens are indexed in memory. This requires 384 bytes of free RAM and having level size up to 0x40 screens would require 768 bytes of free RAM which is out of place for shadow RAM ($7E:0000-$7E:1FFF). Not really worth the potential problems for so little gain, specially knowing that only a few users would make a single level have more than 0x20 screens and without vertical scroll at all.

Anyways, I have submitted all of my patch hijacks and changes to the Hijack Map. Have fun on them!

As for the RAM, here is the RAM used by the patch:

Code
; Theoretically, up to 64 screens are possible if we use 768 bytes of free buffer RAM
; instead of 384. But it would cost managing more data and it's not very the kind of
; the purpose aims for.

; $13D7 is originally only used on OW.
; $0AF5 is cleared on boss clear but it should not matter.

!Screen_Size	= $13D7			; Screen size (so it defaults to e.g. #$01B0)

; Slight risk to this free RAM address being used by another third party ASM hack.
; Probably would be better to edit smkdan's patch and use part of the reserved RAM addresses
; for it or even adapt to use scratch RAM ($00-$0F) for better speed. ADC #$0000 is 3 cycles.
; ADC dp is 4 cycles. ADC addr is 5 cycles. ADC long is 6 cycles.
!Screen_Size_L	= $1936			; Screen size - #$0010. Used to adjust smkdan's patch.

!ExSprite_Flags	= $0BF4			; Holds the currently loaded flags for exsprites

!ExLevel_Flags	= $0BF5			; Holds the currently loaded flags for the level.

; This RAM buffer is originally only used on OW and boss battles.
; Note that part of $0AF6 is used by LM to include the extended color area
; that the original game didn't include. That makes our hack also uses
; part of $0BF6, which makes mandatory to use the 4BPP hack or some additional hijacks
; to clean up it...

; Starting at $0B05 is free!
; IMPORTANT: Skipped first 256 bytes because the RAM area is used by credits.
; Sticking with $0BF6 and forward for tables and backward for RAM values.

!RAM		= $0BF6			; 256 bytes of free RAM. Must be on shadow RAM.

!L1_Screen_Lo	= !RAM			; 96 bytes (32 * 3).
!L2_Screen_Lo	= !RAM+48		; 48 bytes (shared).
!L1_Screen_Hi	= !RAM+96		; 96 bytes (32 * 3).
!L2_Screen_Hi	= !RAM+96+48		; 48 bytes (shared).

; These ones don't need to be on the shadow RAM, though...
!L1_Lookup_Lo	= !RAM+96+96		; 32 bytes
!L2_Lookup_Lo	= !RAM+96+96+16		; 16 bytes (shared)
!L1_Lookup_Hi	= !RAM+96+96+32		; 32 bytes
!L2_Lookup_Hi	= !RAM+96+96+32+16	; 16 bytes (shared)

;Enhanced Sprite System

!Last_X_Boundary	= $0BEE			; Last X boundary.

!Last_Y_Boundary	= $0BEF			; Last Y boundary.

!Y_Range_Min		= $0BF0			; 16-bit; Minimum range for Y.

!Y_Range_Max		= $0BF2			; 16-bit; Maximum range for Y.

					
!Lookup_Pointer		= $0CF6			; 64 bytes of free RAM to hold a lookup table of $CE-$CF
						; pointing to the sprite data beginning at a certain screen.
					
!Lookup_Properties	= $0D36  		; 64 bytes of free RAM to hold a lookup table of level-sprite
						; number plus the current sprite-vertical jump at a certain screen.


Quote
My patch, which is on this e-mail attachment, uses a simple strategy which moving the map16 lookup table to RAM and add a table for setting up the height of the horizontal levels (by default, it's 27 tiles big or #$01B0 blocks). The ASM hack allows for modifying that value and on level initialization it rebuilds the lookup table depending on the level height chosen by user (I added 21 possible combinations. We can reduce it to 16, increase to 32 or even make it fully customizable by user). Based on that, I modify a certain portions of the ROM to use the lookups table, but at the same time all common routines (such as get map16 used on sprites and blocks) will automatically work with the new tables because of the indirect indexing :D

With that, my patch pretty much sets up the new table and adjusts the camera and common objects. The default levels, as far I tested, renders normally and in case an object in particular breaks with a custom level size, nothing avoids from the user use the standard size for it. Compatibility is maximized.


Here is the actual black magic used for custom level sizes.... Remap the screen numbers table to RAM!
GitHub - Twitter - YouTube - SnesLab Discord
Interestingly, Yoshi eating berries works perfectly fine in a level using horizontal mode 1C despite the screens being 28 blocks tall compared to 27 in regular horizontal levels. I even ate green blocks at every Y address in one screen and the correct blocks were replaced. Maybe I'm miscounting? Isn't the reason berries don't work in vertical levels because Yoshi's berry detection code (but not tile replacing code, which works) assumes screens and subscreens are always 27 screens tall while vertical levels are 32 blocks tall and cut into two halves positioned right next to each other?
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 NGB
*reads changing the levels dimensions*
OMG!!!!! Nice integration, thank you very much, this is sooo helpful for me!
Can't wait to get to my laptop to try it out!
Great job!

EDIT: NICE!!
Also really nice additions like the surface view, great update #tb{:]}


Thanks! :) Yeah I figured the surface view could help for people dealing with custom slopes. It's the same approach used with paths in the overworld editor.

Originally posted by Ramon
Also another question: LM now displays normal "Do Nothing" entrances as Mario riding on Yoshi (or what's supposed to be Yoshi, it's using empty sprite map16 slots), is there a way to change that somewhere?


That means you've overridden LM's data for vanilla sprites. You can rename the ROMFileName.m16 file to get rid of your override (or manually update your file by copying the Yoshi sprites into it at the right position).

Or just wait for the 26th...

Originally posted by LucasRCD
Suggestion: An option that's similar to Ctrl + Del (removes everything inside of a level), but it affects all levels in one go. I don't know if this has been suggested in the past, but I feel like this would be at the very least convenient for people who want to start a new hack with all levels being "clean".


Pretty sure someone already made a patch for that a long time ago. It'd just involve resetting level pointers to the "test" levels.

Originally posted by Deeke
Horizontal Scroll Fix all seem to fail spectacularly now, so word of warning to the reckless.


There's an updated patch for that.

Originally posted by Deeke
Lastly, I feel a bit selfish asking for new features right after the boatload of new features we just got, but could there be (or is there already) something to make transferring everything from one rom to another a bit easier? Saving every level individually to a file and then reloading them on another rom takes a while, especially since secondary exits often don't get loaded in on the first pass.


Already exists. See the "Import Multiple levels to/from Files" menu commands (under "File", "Levels").

Originally posted by Luigi-San
Ooh, being able to have more than one secret exit in a level is pretty sweet. I noticed that while extra goal tape sprites were added in to accommodate this, the same wasn't done for keyholes. Any reason as to why? Just seems weird to have one but not the other.


I didn't exactly add those secret exit goal tape sprites. They're possible to place even in a vanilla game. Except in the original game secret exit 2 was coded to set the submap to Yoshi's Island for some reason, so I had to disable that. And I had to add code to the overworld so they'd trigger the right events. Yet the table responsible for shifting the bits to get the directions to enable was already set up, and the bits to store those direction settings were already free...

I imagine someone will make custom key/keyhole sprites for secret exit 2/3.

Originally posted by Noivern
I was tinkering with level 105 for an unrelated reason, and it seems like Lunar Magic isn't properly deleting objects that spawn tiles outside the new level boundaries when you change the size of a level. Attempting to save 105 after I changed only the level size and nothing else gives me an error that says "There is at least 1 object that is placing tiles beyond the bottom or right side of the last screen in the level."


It's not supposed to. Even for switching to tide or layer 2 levels, LM would only ever delete objects and sprites with an origin point beyond the max level boundaries (basically ones that you would have trouble fixing yourself cause you can't get at them). Objects that are only bleeding off past the level edge you can still resize yourself to fix. That way you don't potentially end up with the ground for your entire level getting deleted, as that object can stretch pretty far.

Originally posted by WhiteYoshiEgg
The reason I found those is a bug I'd like to report: when the main LM window is maximized, the right edge of the inner window is visible (instead of a scrollbar, or the lack of one.)


Can't replicate. Are you running LM with something non-standard (unofficial themes/WindowBlinds/Wine/etc)?

Originally posted by WhiteYoshiEgg
With a level layout like that in the screenshot (brown blocks on layer 2, everything else on layer 1), part of the foreground scrolls along with layer 2. When I move the sprite down one tile (i.e. range 05), layer 2 scrolls down considerably once before locking into the expected up-down pattern.


As the sprite tooltip says, for Y=0 (scroll range 12) you're supposed to set the BG init position to 0 (Absolute 0 in the new system... note that isn't the same thing as the BG= +00 setting). And yes, that means you'll only see the top screen or so of layer 2 visible at any time... that's what the sprite was made for.

The range 5 one you might have to start Mario near the top of the level to use. And again, you'll only see the top screen or so of layer 2.


Remember that just like with the tides, you're not meant to be able to scroll vertically with those. Not even in the original horizontal levels. Going by your screenshot, you might need to code a custom sprite for the effect you're really looking for, or modify the original sprite to support vertical scroll.

Originally posted by Wiimeiser
Also, probably more a bug in LMSW, but moving tiles within the internal emulator screen doesn't graphically update the game screen like it did in previous versions.


Yes, that'd be in the DLL. It probably needs to be updated by someone.
I'd also like to point out an oversight in the change of Z-order related mouse wheel controls, as ALT highlights the top menu. Don't know if that's hardcoded into Windows, though...
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 Wiimeiser
Interestingly, Yoshi eating berries works perfectly fine[...]

New level settings are still considered horizontal levels despite everything, internally. So yeah, it works just fine.
Your layout has been removed.
Originally posted by Wiimeiser
I'd also like to point out an oversight in the change of Z-order related mouse wheel controls, as ALT highlights the top menu. Don't know if that's hardcoded into Windows, though...


Technically the keyboard shortcut for it is Ctrl+Alt (where that doesn't happen), not Alt+Ctrl.

Hiding the keyboard shortcut underlines unless Alt is pressed by itself is just a windows setting (you can turn it off in Ease of Access Center on Win7 if you really want).

Tool