 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
| Acmlm's Board - I2 Archive - - Posts by mikeyk |
| Pages: 1 2 3 4 5 6 |
| User | Post | ||
mikeyk Koopa Level: 18 Posts: 101/110 EXP: 25086 For next: 4811 Since: 07-17-04 Since last post: 45 days Last activity: 44 days |
| ||
| I've traced the chargin chuck code completely because i had the same worry that sprite 96 was useds somehow. From what I've seen, 96 never gets written to the sprite table. All chucks branch to the appropriate code based on their sprite number. 96 is never looked for, so it gets to the default case of the normal chargin chuck. I am fairly certain that it is completely unused. I I feel completely confident that 12, 69, 36, 96 are okay to be replaced. After I realized that 17 and 53 were used I took a quick look through the ROM to see if I could find any instances of 85 or 88 being written to the sprite table. Since I never found this occuring, I've overwritten these sprites as well. So far I havent seen any negative side effects in doing this, but I cant say for sure as of yet that there arent. edit: After looking at the code that 85 executes, I'm pretty certain that it is unused. Looking at sprite 88 was a little more interesting, it apparently goes along with the cage in the unused Layer 3 image thread, check over there for the info. (edited by mikeyk on 08-12-05 12:39 AM) |
|||
|
mikeyk Koopa Level: 18 Posts: 102/110 EXP: 25086 For next: 4811 Since: 07-17-04 Since last post: 45 days Last activity: 44 days |
| ||
| Work related to sprite creation has led me back here with another discovery about the cage image. It's now even more apparent that it was meant to be a cage or at least some sort of transport for mario. Sprite 88 determines the placement of the cage, causes mario to start inside of it, and also adds some animation to its top. Mario can move around within the cage, but from my experiments can't escape this in LM:  leads to this in game:  maybe it was belonged to an autoscroll level where mario was trapped in a cage/elevator (edited by mikeyk on 08-12-05 12:59 AM) |
|||
|
mikeyk Koopa Level: 18 Posts: 103/110 EXP: 25086 For next: 4811 Since: 07-17-04 Since last post: 45 days Last activity: 44 days |
| ||
| In my hack I made the bullet bill generators be x/y dependent, so I could have cannons like SMB3. They still shoot bullet bills, but use the fish gfx which i changed to look like cannon balls in my hack. I don't remember precisely, but it goes something like an even x position will yield a normal generator. An odd x position with a even y position will yield a cannon that shoots up, an odd x position with an odd y position will yield a cannon that shoots down. I checked my notes, and with the following info you should be able to repair your problem this with a hex editor. Just change the values to match those of the original SMW. bills/cannons jumps at SNES locations: $01/9F23 $01/8FFE $02/B49D $02/B4B1 y speed at ROM address: 0x91DF (edited by mikeyk on 08-24-05 09:11 PM) (edited by mikeyk on 08-24-05 09:12 PM) |
|||
|
mikeyk Koopa Level: 18 Posts: 104/110 EXP: 25086 For next: 4811 Since: 07-17-04 Since last post: 45 days Last activity: 44 days |
| ||
| All sprite tables are C8 in size. MWR has no effect on sprites C9 and higher, except for corrupting some data of others. SNES $02/B466 is the start of the bill generator. I believe ASM pointers for C9 and higher begin at ROM 0x135B0. It may help for you in tracing to know that SNES $00/86F7 is the instruction that is always responsible for calling a sprite's code (edited by mikeyk on 08-26-05 07:28 PM) (edited by mikeyk on 08-26-05 07:45 PM) (edited by mikeyk on 08-26-05 07:49 PM) |
|||
|
mikeyk Koopa Level: 18 Posts: 105/110 EXP: 25086 For next: 4811 Since: 07-17-04 Since last post: 45 days Last activity: 44 days |
| ||
| A quick note to go along with my last post in this thread... sprite pointers over C9 use bank 02. | |||
|
mikeyk Koopa Level: 18 Posts: 106/110 EXP: 25086 For next: 4811 Since: 07-17-04 Since last post: 45 days Last activity: 44 days |
| ||
| bio: see my posts in this thread http://board.acmlm.org/thread.php?id=17997 | |||
|
mikeyk Koopa Level: 18 Posts: 107/110 EXP: 25086 For next: 4811 Since: 07-17-04 Since last post: 45 days Last activity: 44 days |
| ||
| Ringo: PC 0x899D is the correct address for the start of the hammer bro code. I'm not sure what you've tried to do that would have you thinking otherwise | |||
|
mikeyk Koopa Level: 18 Posts: 108/110 EXP: 25086 For next: 4811 Since: 07-17-04 Since last post: 45 days Last activity: 44 days |
| ||
| You can easily make a plant like that using MWR by pasting the classic piranha code to sprite 36. Ringo: I can look later on as to why the placement is off when you do this | |||
|
mikeyk Koopa Level: 18 Posts: 109/110 EXP: 25086 For next: 4811 Since: 07-17-04 Since last post: 45 days Last activity: 44 days |
| ||
| is this the shelless koopa or regular that you're having a problem with? | |||
|
mikeyk Koopa Level: 18 Posts: 110/110 EXP: 25086 For next: 4811 Since: 07-17-04 Since last post: 45 days Last activity: 44 days |
| ||
| Make sure the blue shelless tile data hasnt gotten corrupted ROM 0x9D93 E0 - blue shelless walk 1 E2 - blue shelless walk 2 E2 - blue shelless turning CE - unused? E4 - blue shelless kicking E0 - blue shelless struggling 1 E0 - blue shelless struggling |
| Pages: 1 2 3 4 5 6 |
| Acmlm's Board - I2 Archive - - Posts by mikeyk |
