Language…
22 users online: Aclais,  Ahrion, Batata Douce, crm0622, Ekimnoid, Gamet2004, Golden Yoshi, Green, Hidincuzimsmokin, koffe190,  MarioFanGamer, masl, neidoodle,  Ringo, RZRider, Scags, schema_tuna, shaoshao, sinseiga, StarWolf3000, sugarfish456, TheXander - Guests: 267 - Bots: 253
Users: 64,795 (2,376 active)
Latest user: mathew

Lunar Magic suggestions and discussion (LM v3.40)

Tool

Following up on this post, I was wondering if you could go into more detail on the "2-7 Only used for full game Map16 export/import, so set to 0". I was unable to find a complete specification for this part of the format anywhere else.
That's all Map16 data, so it's effectively the same type of format you'd find in index 0.
I'm mostly wondering what the semantic meaning for each of the indices is. Presumably for a full map16 export there'll be one to all FG tiles, one to all BG tiles and so on, no?

EDIT: At this point I think I know the meaning of all pointers, the only real question I have left is what the "4 bytes extra flags" and "4 bytes for various flags and info" are.
Minor feature request: Would it be possible to add an "-ExpandROM" command to Lunar Magic's command line interface?

Usage could be something like:

Code
; Expands to 1 MB:
"Lunar Magic.exe" smw.smc -ExpandROM 1

; Expands to 2 MB:
"Lunar Magic.exe" smw.smc -ExpandROM 2

; Expands to 4 MB:
"Lunar Magic.exe" smw.smc -ExpandROM 4

; ...


The reason is that I have written a pretty neat and useful manager/test suite for myself to help with testing of my patches. I just select the patch to apply, configure options like ROM size and ROM type (SA-1 or not), and then a little Python helper script takes care of everything else (patching the correct patches, inserting required blocks, levels, GFX etc.).

Previously, to do this, I had to keep a bunch of different base ROMs around, expanded to various sizes via Lunar Magic, and either with or without SA-1 Pack applied. Since I can't commit copyrighted ROM files to GitHub, potential collaborators would have had to do the same and create all these base ROMs from scratch. As you can imagine, this was a rather impractical solution, so I wanted to rewrite my test suite to always start with a clean SMW ROM and automatically apply all required base patches and hacks. That way, potential collaborators would only have to copy a single clean SMW ROM file into the baserom directory to get started.

Now all of this actually works fine, but I have run into some minor issues regarding the interaction between SA-1 Pack and Lunar Magic. If I modify a ROM via Lunar Magic before patching SA-1 Pack, the ROM crashes. If I patch SA-1 Pack before modifying the ROM via Lunar Magic, it seems to work, but Lunar Magic gives me the "your checksum has been tampered with" warning message box, which is of course a minor annoyance in an automated test script and makes it feel like something went wrong.

The only way I found to avoid both issues is to expand the ROM via Lunar Magic first (without touching literally anything else in it), and then patch SA-1 Pack. Unfortunately, there currently doesn't seem to exist any Lunar Magic command line function which only expands the ROM without doing other modifications. Of course I could create a small .bps patch which applies Lunar Magic's base hacks to the ROM, but again, that seems like an impractical solution that makes it more tedious to switch to newer LM versions in the future. Hence my feature request here.

I know this is definitely a very niche application, but I thought maybe it's simple enough to add, so I'd ask anyways.

In order for this command to work properly from the command line, it would also have to automatically skip the "Are you sure?" confirmation prompt. I think this should be fine to do, since the only people using the command line interface are probably ones who do know exactly what they're doing. Probably just people going for automation themselves.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Originally posted by underway
EDIT: At this point I think I know the meaning of all pointers, the only real question I have left is what the "4 bytes extra flags" and "4 bytes for various flags and info" are.


The first one doesn't have anything at the moment. For the one after the X/Y however, the low bit is for enabling tileset specific tiles on page 2 for the ROM, and the next bit should be enabled to indicate a full game Map16 export file (the next 2 bytes may be set but they're not currently read).


Originally posted by RPG Hacker
I know this is definitely a very niche application, but I thought maybe it's simple enough to add, so I'd ask anyways.


Maybe. I did briefly consider adding ROM expansion back when I was adding more commands, but wasn't sure if it would get enough use to bother with considering there are likely multiple other ways people can expand the ROM.
Originally posted by FuSoYa
Maybe. I did briefly consider adding ROM expansion back when I was adding more commands, but wasn't sure if it would get enough use to bother with considering there are likely multiple other ways people can expand the ROM.


Yeah, there certainly are. Although all the ones I know will make Lunar Magic display that checksum warning box (which of course isn't really an issue for 99% of users. I just so happen to fall within that remaining 1%). Definitely still a feature with niche applications, but at least not entirely useless.

FYI, my current solution that works was to write a little .asm patch to replicate Lunar Magic's header. That successfully gets rid of the warning. I don't know if this already counts as reverse-engineering ASM hacks in your book (since I know your stance on that), but it's literally only a text string and a few random bytes, so I hope it'll be fine.

It's still not a perfect solution, since this patch will always turn the ROM it one modified with LM 3.31 specifically. Though I assume this won't be a problem, since Lunar Magic has upgrade paths for all new versions.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Is there a way to turn off the tileset-specific behavior of objects 2E-3F and make Lunar Magic always treat them as belonging to a particular tileset?

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Originally posted by RPG Hacker
It's still not a perfect solution, since this patch will always turn the ROM it one modified with LM 3.31 specifically. Though I assume this won't be a problem, since Lunar Magic has upgrade paths for all new versions.


While there's no way to know what might happen in the future, if it's just copying the setting bytes at the end of the original ROM space it'd probably be fine for now. The program version string isn't currently used for determining upgrades either, so again unless something changes in the future it shouldn't affect LM.

Originally posted by imamelia
Is there a way to turn off the tileset-specific behavior of objects 2E-3F and make Lunar Magic always treat them as belonging to a particular tileset?


There's no separate setting for that. It's controlled with the FG/BG GFX index.
Originally posted by FuSoYa
There's no separate setting for that. It's controlled with the FG/BG GFX index.

Well, yeah, I guess I can't think of many cases where just changing that would create a problem. Making them all global would save a little bit of ROM space and level loading time, but it wouldn't mean much.

While we're still on the subject of objects, I'm kind of curious about some of objects 22-2C as well. Several of them are deprecated and presumably only kept around for backward compatibility, but some of them also have unused bits. Objects 25 and 26 each have 8 of them, for instance, and object 28 has 4. Perhaps those could be used as a subroutine index pointer of sorts for alternate uses of those objects? (I assume that they're always 0 in hacks that are old enough to actually use them.)

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
I don't think there are many alternate uses that would be all that useful for the remaining bits other than more settings (which is what they were originally set aside for in case they were needed). Certainly not custom objects, as you're already starting out with one byte gone.
They could be used for additional header/bypass settings, though. Or maybe, like, HDMA if that ever became a Lunar Magic feature.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
...well, yeah? As I just said, they were set aside for potential future settings. The extra bits in object 26 were originally going to hold the level animation settings back in 1.70, before I decided to put them in a table instead.

I've generally been avoiding using more objects to hold settings that might be better off in a table these days, as while it may be convenient it's probably not the best use for what's effectively a limited resource (standard object numbers).
I would like to suggest having the Palette Animation tables extended past 11D00; I would like to be able to put my palette ExAnimation data in ExGFX60, but that is next to impossible with the current limitations on it.
You can put palette ExAnimation data in ExGFX60. You just have to check "Use alternate ExGFX file for source".

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Is there any way that I can disable the Layer 2 tilemap automatically updating when the screen scrolls? I'm trying to use it for a single object that I'll move around manually, so I want the whole tilemap to upload at once but then never get changed.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Originally posted by imamelia
Is there any way that I can disable the Layer 2 tilemap automatically updating when the screen scrolls?


Assuming you're talking about when the VRAM patch is installed... I suppose if you set the 16 bit values of $7F8313 and $7F8315 to the value of $1E & #$FFF0, and $7F8317 and $7F8319 to the value of $20 & #$FFF0 before the code hijack at $0586F7 can run each frame, then the VRAM patch should be fooled into thinking that no layer 2 VRAM update needs to occur during gameplay.

Originally posted by imamelia
I'm trying to use it for a single object that I'll move around manually, so I want the whole tilemap to upload at once but then never get changed.


If by the "whole tilemap" you mean the full 512x256 layer 2 tilemap in VRAM, I should point out that the VRAM patch generally only gives you the portion of the tilemap visible on the screen. You'll likely need to upload a tilemap yourself if you want more than that.
Yeah, I specifically want the full 512x256 tilemap. I tried uploading it myself, but the VRAM patch still seems to be interfering.

Also, if you're using a manual ExAnimation trigger and want to update immediately when it changes, is there anything you have to do besides making sure that all of a set of 8 contiguous slots (such as 00-07) are set to use it? I'm having trouble getting it to work, and it doesn't seem to be the fault of my code, since the debugger says that $7FC070 is indeed changing every frame. It looks like it's storing alternating values to $7FC080-87, though, so it keeps thinking that it's already showing the correct frame.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Originally posted by imamelia
Yeah, I specifically want the full 512x256 tilemap. I tried uploading it myself, but the VRAM patch still seems to be interfering.


Make sure you upload after the VRAM patch has already done its own initial upload during level load.

Originally posted by imamelia
Also, if you're using a manual ExAnimation trigger and want to update immediately when it changes, is there anything you have to do besides making sure that all of a set of 8 contiguous slots (such as 00-07) are set to use it? I'm having trouble getting it to work, and it doesn't seem to be the fault of my code, since the debugger says that $7FC070 is indeed changing every frame. It looks like it's storing alternating values to $7FC080-87, though, so it keeps thinking that it's already showing the correct frame.


When you change the manual frame #, set the frame counters for your slots ($7FC080-87 in this case) to some frame value you're not using like #$FE so it will always force triggering the transfer.

But note that if you're not actually changing the value every frame and want to be more efficient, you'd want to instead only store that #$FE to the frame counter of the slot that's going to be uploaded for the current game frame ($14 & #$07, though it might be +1 depending on if your code is running before or after the ExAnimation code) while setting the rest of your frame counters to the new frame value you're changing to. That way you're only doing the transfer once instead of repeating the same VRAM transfer for up to the next 8 frames.
Probably a very niche issue, but it's worth the mention just in case: I feel it's weird that custom images to cover the black parts of the editor (you know, the ones you add with .ffx/.ffxhd/.ffx2) get affected with zoom options, especially because in most of the cases they won't be upscaled properly (only pixelart scale properly), and it's even worse if people (like me) uses small resolution pics. I feel like they should ignore the zoom settings and show always at native resolution (or at least have an optional check for both cases).
Layout made by MaxodeX
2021 TRENO vibe check thread
I'd rather not significantly change and slow down the rendering just to accommodate that.

Tool