Language…
18 users online:  Anorakun, AntonioDosGames,  Atari2.0, Aurel509, Dark Prince, deported, gabriel09213535, GrenCarret, Hayashi Neru, Heitor Porfirio, katun24, Maw, Nciktendo, oldyear, Russ, SubconsciousEye, Teaser, Vini2019huebr - Guests: 135 - Bots: 186
Users: 58,145 (2,438 active)
Latest user: 2lonelyjp

Lunar Magic suggestions and discussion (LM v2.52)

Link Thread Closed
  • Pages:
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 143
  • 144
  • 145
Originally posted by Alcaro
As long as all four of those are still JSLs (22), I think LM will leave them alone, but I never tried it. Let's just see what FuSoYa has to say about it.


Given that borrowing those JSLs and then JSLing to LM's Map16 code within his own would cause the stack checks in LM's ASM to fail and disable the custom blocks, it'd be best to insert any new code after LM's hijacks. He may be able to get away with using long jumps to his own code instead, but it's better to avoid playing with LM's hijacks whenever possible since if the ASM is ever updated in a newer version, the hijacks tend to be written again as though it were installing for the first time.

Originally posted by imamelia
I, at least, would like to change the original blocks, since probably three-quarters of the tiles on page 0 are useless for my main hack.


Oh... well if that's all you want to do, I don't think there's anything stopping you from inserting custom blocks as those block numbers already unless BlockTool prevents it for some reason.

Originally posted by imamelia
Also, I came up with an idea for what we could do with level modes 12-1D: have alternate BG modes.


Just keep in mind that if alternate level dimensions are implemented some day, some of those level modes will be needed for that instead. It might be better to just set the screen mode elsewhere.
So, I know this is old, but any more consideration to letting us change the FG map16 page of ExGFX? Or copying individual palette rows?

Because the current system makes inserting stuff like this:

http://www.smwcentral.net/?p=showexgfx&id=2385

and this:

http://www.smwcentral.net/?p=showexgfx&id=3179

Absolute hell. Why? Lots of tiles to have to manually assemble if the sample level's FG page is already in use.
For gaming news and Wario discussions, check out Gaming Reinvented and Wario Forums respectively.

As for Mario's Nightmare Quest? Well, it's currently on Fusion Gameworks, ROM Hacking.net or the GCN at the moment.
Speaking of which, a find-and-replace system for tiles inserted through Direct Map16 Access would be very useful, for when you realize you have been building your level with tiles from the wrong page and have to replace every single one. As would a way to export all the different tileset variations of pages 0 and 1 at once; if you have done even the slightest of changes to them (such as making all the switch blocks solid), porting Map16 data to a new ROM suddenly becomes rather painful.
My YouTube channel
Get the official ASMT resource pack here!

Originally posted by yoshicookiezeus
Speaking of which, a find-and-replace system for tiles inserted through Direct Map16 Access would be very useful, for when you realize you have been building your level with tiles from the wrong page and have to replace every single one. As would a way to export all the different tileset variations of pages 0 and 1 at once; if you have done even the slightest of changes to them (such as making all the switch blocks solid), porting Map16 data to a new ROM suddenly becomes rather painful.


I agree entirely. I'm in the exact same situation myself, trying to move all graphics that use one page to use a different (identical one) as to save map16 space.
For gaming news and Wario discussions, check out Gaming Reinvented and Wario Forums respectively.

As for Mario's Nightmare Quest? Well, it's currently on Fusion Gameworks, ROM Hacking.net or the GCN at the moment.
I actually made a program to do that...but I agree, I'm hoping that will be included in the changes to the Map16 editor.

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

I'm working on a hack! Check it out here.
Originally posted by cheat-master30
So, I know this is old, but any more consideration to letting us change the FG map16 page of ExGFX?


If you mean remapping existing Map16 tiles to use different 8x8s, then yes, that's been included in the new Map16 editor.

Originally posted by cheat-master30
Or copying individual palette rows?


Already in the next version.

Originally posted by yoshicookiezeus
Speaking of which, a find-and-replace system for tiles inserted through Direct Map16 Access would be very useful, for when you realize you have been building your level with tiles from the wrong page and have to replace every single one.


While remapping DM16 objects in a level isn't in yet, it was next on the list to add before the next release, so it'll probably get in.

Originally posted by yoshicookiezeus
As would a way to export all the different tileset variations of pages 0 and 1 at once; if you have done even the slightest of changes to them (such as making all the switch blocks solid), porting Map16 data to a new ROM suddenly becomes rather painful.


Fortunately this occurred to me while doing the new exporting/importing code, so it's already in the new Map16 editor.
Wow sounds like there are some huge notable updates in the next version. I look forward to it. Also given the limitations of SMW, I have no idea if this is possible (but I imagine it is), but it would be awesome to see a layer 3 tile editor for levels.
SMWC's official dentist since 2011.

YouTube - Twitter - Twitch
If the ROM is larger than two megabytes, please put as much data tables as possible in banks $40+ (except, of course, if that area is full), so banks $3F and lower (where $xx0000-$xx1FFF is RAM instead of ROM mirrors) can be used for patches.
There's no point in expanding 1MB ROMs, but for 4MB ROMs, it could be the difference between getting this problem and not getting that problem.
<blm> zsnes users are the flatearthers of emulation
What bothers me about this is that it doesn't exactly solve the main problem... people installing patches in locations they weren't designed for. If a patch isn't going to run in banks past 3F, it should clearly say so. LevelASM currently says to "preferably" install below bank $40, but with the code it has at the moment it's not just preferred, it's required.

Not very familiar with xkas, but to make it a little more visible for people it looks like one could also put something like this just after the ORG !FreeSpace line (and then just make sure if it does |800000 for FastROM, that it's done where FreeSpace is defined and not on the ORG line):

warnpc !FreeSpace&$800000|$400000 ;display error if patch not within ROM banks 00-3F or 80-BF


Wonder if it might be worthwhile to go through the patches on the site not confirmed to be compatible to run in banks 40+ to add that...
Most people who want to apply patches stick them in the first freespace they can find. The more stuff you put in $40+, the higher the chance that an usable freespace address is on the top - and the higher the chance one of the usable addresses is picked. This means that if LM claims $40+ as early as possible, it will solve, or at least lessen, the problem. Data takes much more space than ASM, so there's no risk $10-$3F will be filled before $40-$7F.
Just don't try to install the gfx+2 patch there.

Oh, and org $000001 : warnpc !Freespace&$400000 should work just as well. It depends on personal preference or something, I guess.
<blm> zsnes users are the flatearthers of emulation
Originally posted by Ayosuf
Just keep in mind that if alternate level dimensions are implemented some day, some of those level modes will be needed for that instead. It might be better to just set the screen mode elsewhere.

Just popping in to say i saw this and if it ever does become a reality in the future, I will shit my pants in excitement and probably start hacking again. Just imagine what could be done with taller levels...
TBH I think it best to assume (at least for newbies) that all patches just don't work in bank $40+.

I've always worked with a 2 mb rom but if/when I do move up to a 4 mb one, LM sticking whatever it can in banks $40+ will be hugely convenient. I don't want to do that shit manually if I need more room for patches.
Originally posted by Ayosuf
What bothers me about this is that it doesn't exactly solve the main problem... people installing patches in locations they weren't designed for. If a patch isn't going to run in banks past 3F, it should clearly say so. LevelASM currently says to "preferably" install below bank $40, but with the code it has at the moment it's not just preferred, it's required.

Except that ANY patch that references non-24-bit RAM addresses won't work in banks $40 and up. (Edit: Okay, make that "any patch that references 16-bit RAM addresses". I forgot that direct page addresses always assume the bank to be 00.)

Also, this is something of an annoyance with other tools, too...Sample Tool, for example, won't let you manually select which banks to use for samples; it just places them in the first empty bank that is available, which is kind of annoying. (I plan to simply insert my sample banks manually, using Sample Tool only for inserting the necessary hacks.) I suppose one workaround for this problem would be putting a RATS tag at the start of each bank left over from 00-3F after installing all of Lunar Magic's ASM hacks. How many ASM hacks does Lunar Magic install, anyway? Or, how many actions must one perform in the editor to ensure that every hack gets installed? (Saving a level, saving the overworld, inserting GFX and ExGFX, changing the compression method [if desired], enabling FastROM [if desired], using at least one ExAnimation slot...?) I could make an IPS patch that adds all of those hacks and put it in my Dropbox folder for others to use or something.

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

I'm working on a hack! Check it out here.
Originally posted by Alcaro
Most people who want to apply patches stick them in the first freespace they can find. The more stuff you put in $40+, the higher the chance that an usable freespace address is on the top - and the higher the chance one of the usable addresses is picked. This means that if LM claims $40+ as early as possible, it will solve, or at least lessen, the problem.


I imagine some do and some don't. The effectiveness would also be somewhat reduced for those that wait until the first 2 MB of the ROM are already used before it's auto-expanded by LM to 3MB. Not much we could do about that though beyond suggesting that people who use numerous patches might want to expand the ROM early on, as I don't think it's reasonable to have LM auto-expand ROMs to 3-4MB right off the bat for everyone.

Originally posted by Alcaro
Just don't try to install the gfx+2 patch there.


Why not? Pretty sure I gave it a quick look over when first adding it to make sure it wouldn't have install location issues.

Originally posted by imamelia
Except that ANY patch that references non-24-bit RAM addresses won't work in banks $40 and up. (Edit: Okay, make that "any patch that references 16-bit RAM addresses". I forgot that direct page addresses always assume the bank to be 00.)


Not true. You can just leave the data bank register as-is after a hijack (normally less than 10), and use long addressing when accessing ROM tables. While it is a bit more efficient being able to access ROM tables with 16 bit addressing, in most cases it's not worth giving up install location flexibility. It's what I usually do with LM's ASM hacks if they're to be installed in the expanded area, so I don't have to care about which bank they're getting installed to. LM installing one of its ASM hacks in banks 40+ when it doesn't function there is something I'd consider to be a bug in LM.

There might not be much one can do if a tool relies on user supplied code, yet it would be nice if other ASM and tool authors did a little more due diligence regarding this issue.

But, meh... if most of the patches on SMWC really are in that state, then how about a compromise? If someone wants to go through all the patches on the site to add some variation of the warnpc statement (except for ones where it's obvious that it's not an issue) so that users have at least some feedback when installing to a free space location it's not going to work from, I'll add an on-by-default option to LM to prefer saving data/code in banks 40+ when the ROM is larger than 2MB. That way we've done what we can to deal with the problem at both ends.
I know this doesn't really relate to the current discussion, but could we integrate this patch, perhaps? It allows hackers to use tiles 69 and 83 (so you can have full size koopa heads, for example).
Originally posted by Ayosuf
The effectiveness would also be somewhat reduced for those that wait until the first 2 MB of the ROM are already used before it's auto-expanded by LM to 3MB.

Some users expand their ROMs to four megabytes the first thing they do.
I have no idea why.

Oh, and if graphics are reinserted (or something like that), 300 (or whatever) kilobytes of data would be shuffled around.

Quote
Why not? Pretty sure I gave it a quick look over when first adding it to make sure it wouldn't have install location issues.

...what. You're making your patches $40+-compatible?
In that case, it should work fine.

Quote
If someone wants to go through all the patches on the site to add some variation of the warnpc statement (except for ones where it's obvious that it's not an issue)

We do have some other stuff we want to do with the patches (mainly ensuring all of them works on bsnes), but I don't think it's a good time for that right now. The RAM map is pretty messy right now, and I'd prefer getting it clean before we start having fun with the patch section.
If someone else wants to start it, I won't complain, but I won't start it myself until the RAM map is cleaned out (we also want to remoderate the ROM map, but that could be delayed).

Quote
on-by-default

Is there any reason to ever turn it off?
Whatever, it's your tool.
<blm> zsnes users are the flatearthers of emulation
Wait...you're not willing to support headerless ROMs (and various other things), but you're okay with taking the extra time to make stuff work in banks 40+? How does that make sense? Whatever, though.

I also will be starting off with a 4 MB ROM, but only because I have over 17 banks' worth of dynamic sprite graphics, 5 sample banks, HDMA tables, and other stuff, and that seems like way too much raw data to put in a lower bank.

And yeah, technically you could deliberately not change the data bank in a hijack, but...do you have any idea how many times forgetting a data bank wrapper has screwed me up when making a patch? And personally, the fact that xkas defaults to the longest ROM address possible (LDA Table,x will be 24-bit) has always been an annoying "feature" to me. Besides, what happens if you want to index a ROM address with Y instead of X?

Also, what about having an option to install all of Lunar Magic's ASM hacks at once (or at least have a menu for which ones should be installed and which shouldn't)? Then all the necessary code would already be in the ROM before the user would start on anything like inserting patches, music, graphics, etc.

There's another thing that I brought up a while back that I'd like to mention, too, although it is unrelated to the whole code/data/bank selection thing. Could you please make it possible to switch the larger dropdown menus in the "Modify Level Tile Settings" menu in the overworld editor to simple input boxes (just like the option that does that for the Super GFX Bypass menu)?

...And while we're on the subject of the overworld editor, I just noticed a typo: The "Destroy Level Tile Settings" menu says "Event Number to destory this level tile on".

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

I'm working on a hack! Check it out here.
Originally posted by imamelia
Wait...you're not willing to support headerless ROMs (and various other things), but you're okay with taking the extra time to make stuff work in banks 40+? How does that make sense? Whatever, though.

He enforces headers to get rid of the trouble with figuring out whether an IPS patch is for a headered ROM or not. You don't need to agree, but I understand his reasoning and agree with it.
Unless we somehow make sure people who don't know what they're doing will always get headered ROMs (for example autoheadering .smc ROMs and asking what to do with .sfc ROMs, or a registry-only option), I oppose transparently accepting unheadered ROMs. Our members confuse themselves enough as it is (just check Basic SMW Hacking for a while), we don't need to give them another way to get confused.
<blm> zsnes users are the flatearthers of emulation
I think stuff like that could be solved by burying an option somewhere where a newbie couldn't find it easily, but again, whatever...
I wish there was something in the Map 16 tile editor where you could copy/move a map 16 page to another and if there where already tile on the page you wanted to paste on, the one you copied/moved would fill in the empty spaces. Like this:

Lets say you copied the one on the left, and you wanted to paste it one the right.



when you pasted it, it would do this:


  • Pages:
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 143
  • 144
  • 145
Link Thread Closed