Points of Required Attention™
Please chime in on a proposed restructuring of the ROM hacking sections.
Views: 88,544,163
Main | FAQ | Uploader | IRC chat | Radio | Memberlist | Active users | Latest posts | Calendar | Stats | Online users | Search 05-06-24 04:19 AM
Guest: Register | Login

0 users currently in SMW Hacking | 1 guest

Main - SMW Hacking - Lunar Magic 1.81 New thread | New reply


Tuyukosi
Posted on 10-28-10 11:57 PM Link | Quote | ID: 137410


Shyguy
Level: 22

Posts: 80/81
EXP: 54446
Next: 3904

Since: 01-27-09
From: #tuy

Last post: 4819 days
Last view: 819 days
I wonder why this hasn't been made yet.

here is
The changes, quoted from this thread, 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."

____________________

Haz
Posted on 10-29-10 04:47 AM Link | Quote | ID: 137420


Fuzz Ball
Level: 64

Posts: 580/956
EXP: 2127032
Next: 87065

Since: 03-02-10
From: Michigan, USA

Last post: 4018 days
Last view: 1948 days
Wow, those are some nice changes. Too bad I haven't used lm in a while

Main - SMW Hacking - Lunar Magic 1.81 New thread | New reply

Acmlmboard 2.1+4δ (2023-01-15)
© 2005-2023 Acmlm, blackhole89, Xkeeper et al.

Page rendered in 0.020 seconds. (347KB of memory used)
MySQL - queries: 42, rows: 63/64, time: 0.016 seconds.