 |
|
 |
|
| Lunar Magic 1.80 (and 1.81) released! |
|
Forum Index - SMW Hacking - General SMW Hacking Help - ASM & Related Topics - Lunar Magic 1.80 (and 1.81) released! |
|
|
|
|
| Posted on 2010-09-24 08:17:21 AM |
Link | Quote |
|
You heard me. This is not a joke or a hoax. Lunar Magic 1.81 has been released today, September 24, 2010, the 10th anniversary of Lunar Magic, and it has some pretty nifty new features. Most of them are just upgrades to stuff, but most of them are also PRETTY DARN COOL.
Edit: There, I changed the link to point to 1.81 instead.
Some of the more important things it contains are:
- The "Extension" field for custom sprites has been enabled. This means that sprites can now use more than the normal 3 bytes of data...in fact, they can go all the way up to 0xF! Of course, you have to enable this first. Setting $0EF30F (x7750F) to 42 will enable the feature, and then you set $0EF30C-$0EF30E (x7750C-x7750E) to the SNES address where the data size table is located in the ROM. This is a 0x400-byte table; the first 0x100 bytes are for sprites 00-FF, in order, with an extra bit setting of 0. The next 0x100 bytes are for sprites 00-FF with an extra bit setting of 1, or you could think of them as sprites 100-1FF. (I, personally, will henceforth be thinking of the extension as the new "extra bits" and the old extra bits as the high byte of the sprite number.) The next 0x100 bytes are for sprites 00-FF with an extra bit setting of 2, or sprites 200-2FF if you prefer, and the last 0x100 bytes are for sprites 00-FF with an extra bit setting of 3, or sprites 300-3FF. Now, of course, this won't work without an ASM hack to the sprite loading routine that takes the extra bytes into account, and I have made one for that purpose, although it hasn't been tested very extensively (any takers? see below). GEMS, if it ever gets finished or released, will insert the data size table and set the size for each sprite automatically (possibly using the .cfg editor), but until then, just insert the table and pointer with an xkas patch. The sprite tables used for the extra bytes start at $7FAC00. (So, for example, the fourth byte would be $7FAC00,x, the fifth would be $7FAC0C,x, the sixth would be $7FAC18,x, etc., up to the fifteenth, which would be $7FAC84,x.)
- Direct Map16 Access has been upgraded. Now, you can select multiple tiles at once and paste them as a single object. No more do you need to fill a level full of a bunch of individual map16 tiles if you're using, for example, the Yoshi's Island castle tileset. *level data space++*
- There is a "Conditional Direct Map16" option, which allows you to use the 128 bits from $7FC060-$7FC06F to determine whether or not a particular Direct Map16 object should show up or not. (It doesn't seem to have a keyboard shortcut, unfortunately; it's found in the Edit menu.) If the corresponding flag is not set, the object won't be loaded. By extension, you can check another flag that will make the object always load, but if its flag is set, the Map16 tile numbers will be increased by 0x100. (It's basically the same thing that the switch blocks do in the original SMW.)
- Object 2D is now 5 bytes long and reserved for custom user-defined objects. You have the normal NBBYYYYY bbbbXXXX ssssssss (actually N10YYYYY 1101XXXX, since it's object 2D) thing, and then there's a fourth and a fifth byte after that for other stuff. Once again, though, you can't use this object without the code to take the extra bytes into consideration, which I have also prepared. It's in the link at the bottom. My code uses the third byte as what it normally is, the object XY size, but it uses the fourth byte as the "object number extension", 00 to FF, 2Dx00 to 2DxFF, 2D-00 to 2D-FF, or however you choose to think of it. It stores the fifth byte to $58 (unused RAM, and in the perfect place for something like this), but it doesn't actually do anything specific with it. People, what should we use that fifth byte for? It could just be used as another size/settings byte, but I'm hoping for something a little more creative. I thought of having each bit affect the object in some way, kind of like how Tweaker bits affect sprites, but I don't have any ideas. Can anyone think of anything?
- The overworld graphics are now fully 4bpp...yes, the second half of them included. This would have been nice a while back when I was designing overworld graphics for my hack and didn't have enough flippin' colors for the Layer 1 tiles, but anyway, this should be useful.
- While we're at it, the overworld can now have custom palettes...another thing that would have been nice before. FuSoYa has made some modifications to the style of the palette editors in general (you have to see it to picture it), but the overworld custom palettes were, in my opinion, the most important thing. Note that the same restrictions that path revealing and the like cause still apply.
- There is a built-in backup/restore system. I think restore points are automatically created at certain milestones, such as the first time you save the ROM, but don't quote me on that. It's File -> Restore, and then you can either create a restore point or restore the ROM to the state it was in at a previous restore point you made.
There a couple of other neat features as well, such as viewing a grid over the tiles and inserting Ersanio's FastROM patch (the one that screws up everything changes all relevant addresses), but these are the most important ones.
So, what do you guys think? I made this thread primarily to announce the release, but it is also for discussion and maybe even suggestions. It's not really for discussion of the object and sprite extensions, though...as related to the editor, maybe, but as stand-alone things or for beta-testing purposes, I made a separate thread here for that. I do have some suggestions for features I'd like to see in the future, but I've talked long enough. It's your turn.
Also, I would like to thank FuSoYa for all the hard work and time he's put into building this wonderful tool for us!
|
| Last edited on 2010-09-24 03:48:08 PM by FPzero. |
|
| Posted on 2010-09-24 08:32:21 AM |
Link | Quote |
|
Oh my God, the Overworld updates are the shit!
I didn't get the first thing imamelia described, mainly because I didn't really care about sprites, but the OW and Map16 updates are definitely awesome!
Thank you FuSoYa!
|
|
| Posted on 2010-09-24 08:36:42 AM |
Link | Quote |
|
Originally posted by "Readme"-fixed a bug from 1.70 where the Iggy/Larry battles could glitch
depending on certain conditions. Thanks goes out to Markus for
reporting this.
HOORAY! 
I discovered that glitch when playing around with Mode 7, btw.
|
|
| Posted on 2010-09-24 08:43:40 AM |
Link | Quote |
|
Happy Happy, Joy Joy!!
Conditional Map16 is going to help me a ton!
Also, I'm kinda' confused on the sprite stuff in the first paragraph.
Also also, we need to document which FreeRAM addresses are used. I don't want this to kill my hack (I use a lot of free RAM for my patches).
|
|
| Posted on 2010-09-24 08:43:57 AM |
Link | Quote |
|
"Wow, this was unexpected" is all I can say.
Though I have yet to download it and actually try it out myself, the new features you mentioned sound pretty awesome (the ability to insert multiple Map16 tiles at once especially). Thanks a lot for still being devoted to Lunar Magic after such a long time, FuSoYa.
Oh, and happy 3000th post, imamelia. ;)
|
|
| Posted on 2010-09-24 08:44:51 AM |
Link | Quote |
|
Quick question, I'm too pumped to read that all right now.
Does that mean, we can use each palette row on the overworld and all 16 colors for both, layer 1 and 2?
Oh and while I'm at it: Is it safe to use the new Lunar Magic on hacks worked on with ver. 1.7?
|
| Last edited on 2010-09-24 08:46:27 AM by Buu. |
|
| Posted on 2010-09-24 08:46:49 AM |
Link | Quote |
|
|
Awesome! I can't wait to use this!
|
|
| Posted on 2010-09-24 08:47:57 AM |
Link | Quote |
|
Yeah. Parts of certain palettes (ones used for the path reveal animation and the like) still can't be overwritten, but yes, now the second half of OW GFX, normally used for Layer 1 tiles, can be 4bpp.
And to those who are confused about the sprite extension thing, well, just think of it this way: Instead of sprites that use the extra bit, now we can have sprites that use the extra byte(s).
And thanks, WhiteYoshiEgg.
|
| Last edited on 2010-09-24 08:49:45 AM by imamelia. |
|
| Posted on 2010-09-24 08:50:04 AM |
Link | Quote |
|
|
Didn't we already have that capability? Extra Property Byte 1 and 2?
|
|
| Posted on 2010-09-24 08:51:00 AM |
Link | Quote |
|
|
You can't input values for the extra property bytes 1 and 2 in Lunar Magic itself, though.
|
|
| Posted on 2010-09-24 08:51:23 AM |
Link | Quote |
|
This is pretty cool. I recall a little bird telling me about the backup system not too long ago, and it sounded intriguing. I guess we'll have to see how it works.
The rest of the stuff is nice too, especially the Conditional Map16 and custom map palettes. Neat.
|
|
| Posted on 2010-09-24 08:52:10 AM |
Link | Quote |
|
Well, that was fast.
Now I really have to finish up GEMS before someone else tries to make a spritetool compatible with extra bytes.
Either way, that's a lot more features than I thought would come up. Cool.
@ASM: no. The Extra Property bytes were on a pre-sprite number basis, so they were inserted with the CFG file and remain the same for all instances of the sprite. Extra Bytes can change for every time you place the sprite in a level.
|
|
| Posted on 2010-09-24 08:56:25 AM |
Link | Quote |
|
I see what you're saying about the sprite thing now.
So, instead of having this:
34 healthmaxup1.cfg
35 healthmaxup2.cfg
36 healthmaxup3.cfg
37 healthmaxup4.cfg
38 healthmaxup5.cfg
39 healthmaxup6.cfg
3A healthmaxup7.cfg
3B healthmaxup8.cfg
I could write in the extra byte into the sprite code using LM to tell it which health sprite to spawn? That would save me a lot of room on my sprite list because the health sprites set a different bit depending on their first extra byte.
[edit]
I still haven't tried it out yet. I want to know if it will kill my 1.71 ROM.
|
| Last edited on 2010-09-24 08:58:42 AM by ASM. |
|
| Posted on 2010-09-24 09:05:05 AM |
Link | Quote |
|
Originally posted by ASMI see what you're saying about the sprite thing now.
So, instead of having this:
34 healthmaxup1.cfg
35 healthmaxup2.cfg
36 healthmaxup3.cfg
37 healthmaxup4.cfg
38 healthmaxup5.cfg
39 healthmaxup6.cfg
3A healthmaxup7.cfg
3B healthmaxup8.cfg
I could write in the extra byte into the sprite code using LM to tell it which health sprite to spawn?
Sort of. You'd first modify the ASM code of the sprite to use the first extra byte instead of the extra property bytes. Lunar Magic doesn't actually insert the code for handling the extra bytes, though...more info about that is in this thread.
|
| Last edited on 2010-09-24 09:05:21 AM by imamelia. |
|
| Posted on 2010-09-24 09:20:43 AM |
Link | Quote |
|
Create IPS file for this rom? Apply IPS file to this rom? Selecting multiply tiles?
Dear god yes
|
|
| Posted on 2010-09-24 09:28:22 AM |
Link | Quote |
|
THIS IS EPIC!
Man, I love the stuff he put in it!
|
|
| Posted on 2010-09-24 09:32:55 AM |
Link | Quote |
|
|
Apparently people reported that pasting Map16 tiles crashes their games. Why is mine working fine? Could it be because I'm using a ROM that was edited with ver. 1.7? Either way, I'll wait until this has been fixed, just to be on the safe side.
|
| Last edited on 2010-09-24 09:35:23 AM by Buu. |
|
| Posted on 2010-09-24 09:34:21 AM |
Link | Quote |
|
Yup, inserting map16 objects through direct map16 access from pages 3 and above destroys the level it is in.
I don't even have to touch the map16 block, the level just screws up.
Deleting that map16 tile and saving again fixes everything.
|
|
| Posted on 2010-09-24 09:43:06 AM |
Link | Quote |
|
|
Yep. I just pasted a whole house with the direct map 16 thing (selecting a group of tiles). In game, it showed up as a large area of just the top corner tile that was selected. When I touched it, the game crashed.
|
|
| Posted on 2010-09-24 09:52:39 AM |
Link | Quote |
|
|
Delete 1.80 Take 1.71 back (or the one you were using..)
|
|
|
|
|
|
|
Forum Index - SMW Hacking - General SMW Hacking Help - ASM & Related Topics - Lunar Magic 1.80 (and 1.81) released! |
|
|
 |
|
 |
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
|
|
|
|
1 
