 |
|
 |
|
| Lunar Magic suggestions and discussion (LM v2.12) |
|
Forum Index - SMW Hacking - SMW Hack Discussion - Lunar Magic suggestions and discussion (LM v2.12) |
|
|
|
|
| Posted on 2012-02-23 04:02:20 AM |
Link | Quote |
|
|
an option to offset where layer1/2 draws tiles from on a per-level basis. For example if there was a background map16 tile that loaded tiles 00,01,10,11, you could offset layer 2 so the 16x16 tile loaded b00,b01,b10,b11 instead when used in that level.
|
| Last edited on 2012-02-23 12:03:48 PM by jesus. |
|
| Posted on 2012-02-23 04:04:52 AM |
Link | Quote |
|
Originally posted by Wiimeiser
It's not the Porcu-puffer. If a level is only 2 screens and has layer 3 tide and sprite buoyancy enabled, there's a glitch where sprites in the air randomly act like they're underwater. No idea why.
I uploaded a video of this a few months ago, though I have a feeling I'm not the first to discover it.
|
| Last edited on 2012-02-23 04:08:01 AM by Zeldara109. |
|
| Posted on 2012-02-23 04:41:11 PM |
Link | Quote |
|
Three things:
First, I finished the patch I made to make GFX32 and 33 remain uncompressed, if we want to use it. That could allow $088000-$08BFC0 (approximately; the original GFX took up that amount of space) to be used for other stuff as well if anyone wanted...or GFX33 could be placed in that area, taking up $088000-$08AFFF (or $088FC0-$08BFBF) with the original graphics.
Second, would it be worth having an option to get rid of all tileset-specific Map16 behavior, allowing all tiles (on pages 0-2) always to act and look the same regardless of the tileset setting?
Third, what is even the point in $0BF6/$1935? They don't seem to serve a purpose, really, since the Mario Start! graphics don't even come from those tiles, and in fact, skipping the upload routine entirely doesn't even seem to have a noticeable effect on the game. In fact, it might actually be beneficial to do so, since...well, see the entry for ROM address $00A439. Anyone who uses ExGFX for any of those tiles (most notably the sliding Koopa tile) will use that hex edit to bypass those tiles being overwritten anyway, so why even have it at all? Why not just automatically install the hex edit to skip the upload? Actually, on that note, I was making a patch to allow the "Mario Start!" graphics to be uncompressed as well, although the point of that one was more to allow the tilemap to be edited more easily than to save RAM space or anything.
|
| Last edited on 2012-02-24 01:18:09 AM by imamelia. |
|
| Posted on 2012-02-23 05:50:21 PM |
Link | Quote |
|
|
I remember hearing the purpose of that was for the BONUS GAME message, not the MARIO START message.
|
|
| Posted on 2012-02-27 10:59:40 PM |
Link | Quote |
|
This is usually a busy time of year for me, but just to respond to a few things:
Originally posted by EpsilonIs there any advantage to method 1? I noticed that it says "P = Additional pixels", but P = 0 in all the choices. o_O
As I recall the P value is determined by a table in the ROM, but all the values were set to 0. I'd guess Nintendo put it in just in case they needed it later.
Originally posted by EpsilonI always thought method 2 was just an ASM hack.
It is.
Originally posted by EpsilonDoes the "m16-7k" Easter egg still exist? When I try it it just shows the "Enable tileset specific behavior for page 2?" dialogue box, so I was wondering.
It's still there, just trickier to get into because that dialog gets in the way. But even if you do get into it, the feature itself has been mostly broken since 1.90 since it was still set to get the current page number from the old Map16 editor. Both issues have already been fixed for the next version.
Originally posted by EpsilonIs there a reason why we can't modify the internal GFX in the 8x8 tile editor?
Because LM doesn't save it. Have thought about replacing the 8x8 editor much like the 16x16 editor, but people seem to be fairly happy with yychr and there are other things in LM that could be changed that are probably more worthwhile to spend time on. So I've put off making any decision on that one for now.
Originally posted by EpsilonAlso, I just wanted to make sure you saw my last post in this thread since the new version still has that issue.
I saw it, just haven't looked into it yet as it's not a high priority thing.
Originally posted by DiddyKaizo100Hey, I just had a thought if you could install a option to add ExAnimation tiles on the overworld (I know there is a patch for that but...) But make it so there are ExAnimation Pur Submap/Overworld, and the option to disable the original ExAnimation tiles also.
It's been on the list of potential things to do for a while, it just hasn't floated to the top so far.
Originally posted by Ripperon-XAnd just of curiosity: Can BG1 and 2 of the OW allow 4BPP GFX slots, too or only BG3 and 4?
It was already possible to use 4bpp in the first 2 slots.
Originally posted by EpsilonAlso, when I saw this thread it made me wonder... why can't we edit all the colors in the shared palettes, anyway?
Most of the colors that aren't editable are that way because the game doesn't specifically set them for the level, hence there's no existing ROM data in the shared palettes to edit.
Originally posted by EpsilonAnd I just noticed that in the help file on the page "FAQ: How do I create an IPS Patch?" it says you need a separate utility, but I thought you could do that in the file menu now?
Yeah, I should update that a bit.
Originally posted by imameliaDo any of Lunar Magic's ASM hacks explicitly reference $7E2000 or $7E7D00?
If a user sets an ExAnimation to use one of the tiles from GFX files 32 or 33, it will have source frame data that will end up referencing that area.
Originally posted by imameliaSecond, would it be worth having an option to get rid of all tileset-specific Map16 behavior, allowing all tiles (on pages 0-2) always to act and look the same regardless of the tileset setting?
Page 2 has been non-tileset specific by default on new hacks since LM 1.70. As for pages 0-1, that would break the original levels. I think it'd make more sense to make your own custom blocks than change those.
Originally posted by imameliaAlso, now that I think about it, why doesn't Lunar Magic support HiROM format (set aside the fact that most tools don't either)?
The only benefit I know of would be for greater emulator compatibility with 6MB ROMs (due to all emus wanting to be able to run Tales of Phantasia).
Originally posted by DiscoManAlso, there's a bug with the "REMAP" thing in the "16x16 Tilemap Editor", in the dialog where you need to input the value to remap the block (100,25;100-101,25 for example), if you input "space" and then press "OK", LM crashes.
Seems it goes into an infinite loop. Thanks, had heard there might be something wrong in that dialog.  The "Remap DM16" dialog has the same issue. I'll add the fix for the next version.
|
|
| Posted on 2012-02-29 09:47:40 AM |
Link | Quote |
|
|
Well, I tried to see if I can use some 4BPP GFX in the first 2 slots, insrted them and applied them and they were 3bpp. What version had started having the option to insert 4bpp GFX in BG1 and 2? Or was it possible all along and I don't know how.
|
|
| Posted on 2012-03-01 10:16:58 AM |
Link | Quote |
|
Originally posted by AyosufOriginally posted by imameliaSecond, would it be worth having an option to get rid of all tileset-specific Map16 behavior, allowing all tiles (on pages 0-2) always to act and look the same regardless of the tileset setting?
Page 2 has been non-tileset specific by default on new hacks since LM 1.70. As for pages 0-1, that would break the original levels. I think it'd make more sense to make your own custom blocks than change those.
Yes, I know page 2 is non-tileset-specific by default. And yes, it would break the original levels, but any ASM hacks I or others made to do what I said wouldn't be compatible with Lunar Magic anyway because the tiles would show up differently (although I guess if they still functioned in-game...).
Originally posted by AyosufOriginally posted by imameliaAlso, now that I think about it, why doesn't Lunar Magic support HiROM format (set aside the fact that most tools don't either)?
The only benefit I know of would be for greater emulator compatibility with 6MB ROMs (due to all emus wanting to be able to run Tales of Phantasia).
HiROM, not ExLoROM.
Also, that uncompressed GFX thing...can we just have that be the case by default? I mean, that's an awful lot of RAM to throw away just to save what amounts to 0x3307 bytes of ROM space in the original SMW, practically a negligible amount of space in a 4 MB ROM. I see no reason why this couldn't be changed except possible lack of backward compatibility for ExAnimation, and that could be dealt with with a simple find-and-replace.
|
|
| Posted on 2012-03-01 12:29:29 PM |
Link | Quote |
|
Originally posted by imamelia0x3307 bytes of ROM space [...] practically a negligible amount of space in a 4 MB ROM
Ask SNN if he's got 0x3307 bytes of ROM space to spare in SMWCP2.
|
|
| Posted on 2012-03-01 02:14:33 PM |
Link | Quote |
|
|
Well, the SMWCP2 ROM I have still has over 8 banks' worth of free space.
|
|
| Posted on 2012-03-01 10:30:40 PM |
Link | Quote |
|
Originally posted by Ripperon-XWell, I tried to see if I can use some 4BPP GFX in the first 2 slots, insrted them and applied them and they were 3bpp. What version had started having the option to insert 4bpp GFX in BG1 and 2? Or was it possible all along and I don't know how.
It's been possible all along. Provided of course you're inserting the GFX as 4bpp to begin with (check the insertion dialog).
Originally posted by imameliaAnd yes, it would break the original levels, but any ASM hacks I or others made to do what I said wouldn't be compatible with Lunar Magic anyway because the tiles would show up differently.
Depends how it's done. SMW already has tables defining if those tiles are tileset specific or not, which LM follows. There are a few exceptions the table doesn't cover though (for pipes and slanted pipes).
Originally posted by imameliaHiROM, not ExLoROM.
ToP is ExHiROM, not ExLoROM.
Originally posted by imameliaAlso, that uncompressed GFX thing...can we just have that be the case by default? I mean, that's an awful lot of RAM to throw away just to save what amounts to 0x3307 bytes of ROM space in the original SMW.
Yet for someone else, that's a fair amount of ROM space to throw away.
|
|
| Posted on 2012-03-01 11:40:58 PM |
Link | Quote |
|
Originally posted by Ayosuf
Originally posted by imameliaAnd yes, it would break the original levels, but any ASM hacks I or others made to do what I said wouldn't be compatible with Lunar Magic anyway because the tiles would show up differently.
Depends how it's done. SMW already has tables defining if those tiles are tileset specific or not, which LM follows. There are a few exceptions the table doesn't cover though (for pipes and slanted pipes).
I don't see why Nintendo used the switch blocks for the wooden crate, because they could've simply used tiles 2D, 2E and 131 (it doesn't matter in the case of thre red and blue blocks though). Unless they planned the exact arrangement back in 1989...
Oh, and the winged cage needs an autoscroll and ExGFX, and sprite 17 isn't unused. Heck, the slopes aren't tileset specific either
|
|
| Posted on 2012-03-02 01:04:19 AM |
Link | Quote |
|
Originally posted by AyosufOriginally posted by imameliaAlso, that uncompressed GFX thing...can we just have that be the case by default? I mean, that's an awful lot of RAM to throw away just to save what amounts to 0x3307 bytes of ROM space in the original SMW.
Yet for someone else, that's a fair amount of ROM space to throw away.
Okay, then how about at least having it as an option? And I'll bet people don't think to use the unexpanded portion of the ROM, even though if you erased the original level data, the resulting freespace would span over one and a half banks. If anyone needs freespace that badly...
Also, if I edited the source code of smkdan's VRAM hack to allow VRAM addresses to be changed per level, would you be willing to support it in Lunar Magic?
|
| Last edited on 2012-03-05 02:46:05 PM by imamelia. |
|
| Posted on 2012-03-11 08:31:11 AM |
Link | Quote |
|
|
Also, now that we have this, might there be support for SA-1 stuff in a future version of Lunar Magic (not the next version)?
|
|
| Posted on 2012-03-11 08:40:54 AM |
Link | Quote |
|
|
Even if you do, not many people would know how to use it, even if there are some instructions. It's still nice to have it, just in case.
|
|
| Posted on 2012-03-11 09:27:09 AM |
Link | Quote |
|
|
Yes, but even people who know absolutely no ASM would benefit if it installed some code to make certain routines run faster, at least.
|
|
| Posted on 2012-03-11 01:59:22 PM |
Link | Quote |
|
imamelia is the patch you mention not compatible with ZSNES? If yes, there might be a problem with the "Automatic Mario Movements", which requires ZSNES savestates if I'm not mistaken.
Just to make sure if FuSoYa would like to add the patch, there might be a "conflict", so to speak.
|
|
| Posted on 2012-03-11 01:59:39 PM |
Link | Quote |
|
It'll be better if this same resource is applied in sprites because they're using SNES standard CPU instead of the SA-1 one, which means slowdown, doesn't matter if any 'heavy-code' is being processed by SA-1, instead it'll be just a waste of time.
In my sincere opinion, FastROM is enough for our purposes today, maybe in the future, SA-1 can come in handy.
EDIT: Also I agree with imamelia, maybe installing a ASM code to make some routines use SA-1 could be better to make them faster, like sprites I've mentioned above.
|
| Last edited on 2012-03-11 02:07:55 PM by DiscoMan. |
|
| Posted on 2012-03-11 04:38:59 PM |
Link | Quote |
|
Originally posted by Shogimamelia is the patch you mention not compatible with ZSNES? If yes, there might be a problem with the "Automatic Mario Movements", which requires ZSNES savestates if I'm not mistaken.
Just to make sure if FuSoYa would like to add the patch, there might be a "conflict", so to speak.
I think it's possible to give improvised support to SA-1 for ZSNES, but honestly this emulator should have released at least a version with better compatibility.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Also SA-1 is not only for proposed development and acceleration, SA-1 may be also useful for example to remove RAM limitations, larger levels due to HiROM and better effects such as rotation of sprites (graphics).
|
| Last edited on 2012-03-11 04:39:34 PM by Vitor Vilela. |
|
| Posted on 2012-03-11 04:58:18 PM |
Link | Quote |
|
I was wondering what LM could possibly use it for, but larger levels and faster exanimation would be fuck yes.
This suggestion has my support.
|
|
| Posted on 2012-03-11 05:05:35 PM |
Link | Quote |
|
|
Why do Lunar Magic's title screen movements require a ZSNES savestate anyway? Wouldn't it be better to store the movements to SRAM instead, since (as far as I know) .srm files are the same no matter which emulator generates them?
|
| Last edited on 2012-03-11 05:06:11 PM by Zeldara109. |
|
|
|
|
|
|
Forum Index - SMW Hacking - SMW Hack Discussion - Lunar Magic suggestions and discussion (LM v2.12) |
|
|
 |
|
 |
The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.
Copyright © 2005 - 2013 - SMW Central
Legal Information - Link To UsTotal queries: 29
|
|
|
|
