 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| 0 users currently in SMW Hacking. |
| Acmlm's Board - I3 Archive - SMW Hacking - Add 255 sprites? |
New poll |  |  |
| Pages: 1 2 | Add to favorites | Next newer thread | Next older thread |
| User | Post | ||
Smallhacker Super Koopa I AM A Group Of Officially Frustrated Younglings, G.O.O.F.Y. MEMBER |
| ||
| More and more gets uncovered when it comes to sprite hacking, right? Sooner or later, sprite hacking will probably be like custom blocks. There'll be a program that inserts new sprite code to the ROM. However, there's a problem. Unlike custom blocks, one can't add new sprites, only overwrite old (or unused) ones. How to add new sprites?
One way would be to make changes to the level format and give all sprites one or two extra bytes to hold the neccesary information needed to separate the custom sprite from the normal one. However, this would cause incompability with Lunar Magic and would only work if Fu came back and decided to continue working on LM or releasing the source code. Yeah, right. My idea is to assign certain MAP16 tiles to custom sprites. When a block is loaded by the level loading routine, it checks if it's a MAP16 block. If it is, it checks if it's in a MAP16->Sprite table. If it is in there, it ignores the block and places a sprite at that location instead. This would require a new sprite RAM table. An in-game sprite's entry in this table would be "00" if it's a standard SMW sprite. Any non-zero value means that the sprite is a custom sprite. This value is it's custom sprite ID number. It's then used to check a table containing 3 byte pointers pointing to the custom code. This method (which allows 255 sprites to be added) would ignore the sprite's actual ID number. However, it could be used as a second ID number byte, making a total of 65536 possible sprites... If there are that many MAP16 blocks, that is. This method would be compatible with Lunar Magic. All you have to do is to place the MAP16 block you've assigned the sprite to in the level. Did anybody understand what the crap I'm talking about, and if so, any comments? And before you ask, no, I'm not planning on doing this myself. It's just an idea. |
|||
Cirvania Cyball I guess this is as close as Xkeeper will get to spell it right. :<                    Since: 11-17-05 From: The Island of Puerto Rico. Last post: 6301 days Last view: 6299 days |
| ||
| I could see this working sometime in the future.
Implementing this hack wouldn't be THAT hard: the way I see it, the ASM routine would mainly be loading, comparing and branching; somewhat basic ASM stuff, really. We'd need two tables: the one you mentioned with the ID numbers 00 through FF, which would need to be 0xFF bytes long; and the pointer table, which would follow the basic format of: [22 xx xx xx 6B] where xx xx xx is the address where the custom code is located, little-endian. I might work on something like this if I have the time. But, until then... *waits for Bio to show up* |
|||
Raccoon Sam Boomerang Brother Custom Title  Since: 11-20-05 From: Correct Last post: 6299 days Last view: 6299 days |
| ||
| I did.
Wonderful idea. I see no holes in your theory, and I see it coming sometime in the no so distant future. |
|||
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6299 days Last view: 6299 days |
| ||
| Sounds like a nice idea. I can only see two small potential problems:
1) If you use the old sprite ID as half of the new ID, some code might recognize it as being a different sprite. Like if that byte happened to be the ID for a fireball, you might not be able to shoot 2 fireballs. 2) You can't really ignore the block, only place a specific tile. How do you decide which? #0x25 (blank) would work in most cases, but suppose you want to have a custom sprite in front of a ledge? |
|||
|
Glyphodon Since: 11-18-05 Last post: 6340 days Last view: 6320 days |
| ||
| I'm thinking these ideas aren't wonderful at all.
You can't put one atop a block, hijacking the MAP16 isn't cool, checking a new RAM table per sprite isn't fun, and incompatibility with Lunar Magic is totally inexcusable. Doesn't EVERYONE use Lunar Magic for any sort of level or graphical hack these days? Those are messy, messy solutions, and very few custom sprites exist yet anyway. More viable solutions, I believe, would be more sprites that change themselves or other sprites based on their X and Y positions and perhaps Extra Info. Some existing sprites don't seem to even show up if their Extra Info bits are set; there's got to be a way to hijack the code somewhere through that. (edited by Glyph Phoenix on 06-09-06 03:54 AM) |
|||
|
Kailieann Since: 11-18-05 Last post: 6299 days Last view: 6299 days |
| ||
| I don't know much about sprite hacking, but I know enough to know that Glyph's idea is much more sensible. Most of it would just be a matter of changing the sprite's ASM script to check whatever relevant info there is, and branching/jumping accordingly.
It might even be possible to use the sprite's ASM script to overwrite its default properties, giving you the ability to use one single sprite for two (or more) completely different purposes. Using this method, it wouldn't even have to be specific to the enemy's extra info. I've long concidered the possibility of making sprites with level-specific scripts. |
|||
|
Smallhacker Super Koopa I AM A Group Of Officially Frustrated Younglings, G.O.O.F.Y. MEMBER |
| ||
| Personally, I would avoid using X/Y coordinates as much as possible. However, I've come up with another idea.
There's four unused sprites (not counting sprites above D9, as their ASM pointers hasn't been found yet) : 12, Unused. (Points to RTS) 36, Unused. (Points to data) 69, Unused. (Points to RTS) 85, Unused? (Points to junk code?) As you may or may not know, each in-game sprite has got two bits of "Extra Info". This combined with the four unused sprites above gives 4 bits, which allows one to add 16 new sprites. It's also possible to add a table where you decide which 16 custom sprites to use for each level, creating a theoretical limit of 8192 custom sprites in the game. |
|||
mikeyk Shyguy Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
| does anyone know how the extra info bits work? do we know where they are stored in rom/ram so they can be worked with? what sprites use them in the original?
sprites 88 and 96 are unused in my book too. i've never seen the winged cage sprite be put to use, and i don't see it coming soon. the chargin' chuck clone is never referenced and i'm pretty sure that it can be overwritten. |
|||
|
C:/xkas bio.asm Compiled ASM code  Since: 11-17-05 Last post: 6299 days Last view: 6299 days |
| ||
Originally posted by DMiner I would like to know that too  , I think the goal sprite use it in the original to determine if it should activate the normal or the secret exit |
|||
BMF54123 Since: 11-18-05 From: MOOGLES Last post: 6299 days Last view: 6299 days |
| ||
Originally posted by DMinerActually, something does reference that sprite, though I'm not sure how or why. If you change it too much, the leaves on the Jumpin' Piranha Plant start spazzing out, cycling through various colors and tiles. |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
| A corrupted piranha plant is likely a product of using graphic bytes 2 and 3 in MWR. If you happen to have an old ROM that has some issues as a result of editing sprite 96, I'd like to take a look at it. I could probably figure out what's going on. I'm still confident that the chargin chuck clone can be replaced with no side effects. | |||
|
Cruel Justice I have better things to do. Since: 11-18-05 From: At my house! Last post: 6299 days Last view: 6299 days |
| ||
Really, if you have the solution to implement something like this, by all means use it.  So basically sprite editing would be more visual, you can edit the sprite graphic bytes like 16x16 editors. Maybe this could work if you could expand all the lines of codes to somehow to create more unused sprites in the rom and assign new numbers like in Blocktool? |
|||
|
Glyphodon Since: 11-18-05 Last post: 6340 days Last view: 6320 days |
| ||
| This idea would in no way would make sprite editing more visual, Cruel Justice. Smallhacker's idea would make sprite hacking less visual, in fact, because instead of simply pasting the sprites in via LM you'd either have to put a block in to represent one or, using his first idea, not use LM at all. And expanding existing tables is a generally bad idea because there are just easier methods that don't override the existing game's methods.
Anyway, Smallhacker, you're going about this all wrong. Hacking level loading routines is no fun. Sprites are by nature dynamic--there are so many ways to make a sprite act differently. By treating sprites like blocks, which are by nature static, you're totally missing the point. Why not have existing game sprites act differently if their extra bits are enabled? Why not make a sprite break out if it's in a ledge or pop out if it's in a pipe? That's more than possible. Sprites can act completely differently based on any one single bit in RAM or ROM. It's true. You have a lot of bits-- pick one that doesn't mean you can't use LM or that entire loading routines have to be rewritten. |
|||
|
Smallhacker Super Koopa I AM A Group Of Officially Frustrated Younglings, G.O.O.F.Y. MEMBER |
| ||
Originally posted by Glyph Phoenix It was supposed to be a "solution" that wouldn't work. Originally posted by Glyph Phoenix Well... From a level designer's point of view, is there really any difference between a sprite and a block? Both can be placed anywhere in the level, both must be placed in a 16x16 grid (as in, you can't place a sprite nor a block 1 pixel away from another one). In fact, when working with Lunar Magic, the only difference is that sprites can't be resized. (Okay. Some blocks can't be resized, but that's not the point.) The sprite properties that Lunar Magic can change are Command (0-FF), Screen Number (0-1F), X/Y Position (0-FF) and Extra Info (0-3). The MAP16 block properties that LM can change are Block (0-FFF), Screen Number (0-1F), X/Y Position (0-FF) and Size (0-FF). If you ignore the Command and Block parts, sprites have got 15 bits of data while MAP16 blocks have got 21 bits of data, which, technically, means that MAP16 blocks are MORE dynamic than sprites. Anyway. Enough about that idea, since I belive that the other idea, the one that uses extra bits and unused sprites, would be better. (edited by Smallhacker on 06-10-06 05:32 AM) (edited by Smallhacker on 06-10-06 05:32 AM) |
|||
|
C:/xkas bio.asm Compiled ASM code Since: 11-17-05 Last post: 6299 days Last view: 6299 days |
| ||
 , I've finally found where the extra bit is stored in RAM, they are stored at 7E187B(Sprite Stomp Immunity Flag Table) as bit 3 and 4(edited by Bio.exe on 06-10-06 06:20 PM) |
|||
Sukasa Birdo Not quite as active as before. Xkeeper supporter Xk > ||bass I IP Banned myself! Twice!  Since: 11-17-05 From: Somewhere over there Last post: 6300 days Last view: 6299 days |
| ||
| I like that Idea. No holes, no sprite overlapping, etc. GP: You can so- makew the block a copy of a normal one, then have to routine read it as a sprite generation block.
Also, this routine only needs to run once. Then, if you use code $FE (I think $FF means, "No Sprite") for a custom sprite, just have the normal sprite routine ignore that sprite number, and have only your custom routine run it or whatever. Also, you'd only need one RAM table for the extra sprites - use a ROM table for their addresses. |
|||
Skreename Giant Red Paratroopa Since: 11-18-05 Last post: 6305 days Last view: 6299 days |
| ||
| Wouldn't there be a problem with trying to overlap the new block-sprites with normal blocks? Not much of an issue for solid blocks, I know, but I'm sure there are cases in which it could be significant.
(I haven't done too much with it so I don't know all the nuances, so I may not be completely accurate with it...) Otherwise, it sounds decently good. Glyph Phoenix's idea sounds a bit better, but.. that's okay. |
|||
|
Alastor Fearless Moderator Hero  Since: 11-17-05 From: An apartment by DigiPen, Redmond, Washington Last post: 6299 days Last view: 6299 days |
| ||
Originally posted by SkreenameRead the ****ing thread. |
|||
Billiards Koopa Red Paratroopa  Since: 04-21-06 From: Far away from a carnival, one ride tried to kill me (no lie) Last post: 6506 days Last view: 6506 days |
| ||
| I have no clue about ASM, but couldn't you use that program that expands ROMs to create extra space. | |||
|
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6299 days Last view: 6299 days |
| ||
| There's plenty of space. The problem is with modifying the code so that it allows more sprites than there already are, without breaking LM compatibility.
Now if we had LM's source we could just modify the routine it uses for ExGFX, timer/music override, etc, since they already work by adding things into the level data. Another project made unneccessarily difficult due to having to keep compatibility with closed-source software. 
I like the Map16 idea though. AFAIK, the Direct Map16 Access feature can insert blocks up to #FFFF (though I don't think LM would let you do this ), and only up to #FFF are valid. If LM doesn't complain about it, you could break this down into bits like so:
fsss ssss bbbb bbbb f=custom sprite flag, s=sprite #, b=block #. If the custom sprite flag is set, the next 7 bits specify the custom sprite # (0-127), and the remaining 8 specify the block #. This way you could create one of 128 custom sprites overtop of one of 256 blocks. A table elsewhere in the ROM could specify which Map16 page these blocks come from in each level, and if necessary, divide the custom sprites into groups of 128 and use a similar table to specify which group to use in each level. I realize I should probably do some things like see if LM does care about invalid block numbers, and if the block numbers are in fact 16-bit, but I really, really need to go to sleep right now.  |
| Pages: 1 2 | Add to favorites | Next newer thread | Next older thread |
| Acmlm's Board - I3 Archive - SMW Hacking - Add 255 sprites? |
| |
