 |
| 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 |
|
| | ||
| Acmlm's Board - I3 Archive - - Posts by mikeyk |
| Pages: 1 2 3 4 5 |
| User | Post | ||
mikeyk Shyguy                   Since: 02-22-06 Last post: 6449 days Last view: 6294 days |
| ||
| Bio, what table are you looking for exactly? The "location for all the second sprite table" sounds pretty vague to me. You have 0x135B0 which is the start of the pointer table for sprites over C8. If you want to see the handler code for a sprite, just follow the pointer in the table. For example, sprite C9's routine would start at $02B466, CA's would start at $02B3B6, etc. | |||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6449 days Last view: 6294 days |
| ||
| There is no such table. | |||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6449 days Last view: 6294 days |
| ||
| I'm attempting to learn some windows programming. As a porject to get me started, I decided to make a utility like MWR. It is very similar, but should be safer. It won't overwrite any data that doesn't belong to the sprite. Let me know if anyone has any confirmed information about unknown bits or ASM pointers for sprites above D9.
Try it out here |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6449 days Last view: 6294 days |
| ||
| Bio, If you'd like to see how I handled making a 1x1 tile ridable enemy, I've attached the asm code i used to make a smb3 parabeetle. |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6449 days Last view: 6294 days |
| ||
| Hey everyone,
Yes, this is mikeyk now going by a new name. I've been gone quite awhile, but have had some free time lately. I do have a quick update to the program. More previously unknown things are defined now. Get the new version here... Tweaker 1.1 I was hoping to make some more significant changes, but I've been having a little trouble. I need to do some more learning about dialogs before adding anything major, but hopefully I keep interest in this project and turn it into a more powerful editor. |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6449 days Last view: 6294 days |
| ||
| I was indeed planning on putting Graphic Byte 2 in the tilemap dialog, as it is only used for sprites <= 0x53 | |||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6449 days Last view: 6294 days |
| ||
| I've been working more with sprites and getting to know them even better. In the process I've improved the para beetle that i created in the past. I'm sharing the source here for others to use or learn from. It can be compiled and inserted into smw quite easily.
para beetle source  (edited by DMiner on 06-04-06 12:39 AM) |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6449 days Last view: 6294 days |
| ||
| i come with another release. this time its source code for a hammer brother. this is similar to the one that you've seen in my demo and a few others people's hacks. working with asm code rather than hex editing everything has allowed me to pay better attention to detail. this sprite should better interact with walls than the one that i've previously put out there, and should be infinitely easier to get into a hack.
hammer bro asm |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6449 days Last view: 6294 days |
| ||
| yesterday i was messing around, and i ended up doing more sprite work. this time i created a venus fire trap. since i've been doing a lot of work lately, i'm posting my progress on this site here. on that site i also included some simple patches so the sprites can be quickly observed.
here's an image of my latest 
(edited by DMiner on 06-07-06 06:22 PM) |
|||
|
mikeyk Shyguy  Since: 02-22-06 Last post: 6449 days Last view: 6294 days |
| ||
| first of all, i've updated new versions of all the asm files. be sure to hit refresh or redownload the files. i mainly removed the place holder (org $008000) at the begining of the code. this line helped me in what i was doing, but it probably just makes the compiled files more difficult to work with for everyone else.
edit: i also fixed the text formatting problems with all the files on the site. the reason that the binary (hex code) isn't included is that it takes away the portability. if you just compile the code on the site you must insert it at ROM address 0x0C8200 for it to work. this is because the locations of subroutines and other data get hard coded into instructions at compile time. by providing the assembly code, one line can be changed at the begining of the code (org $198000) and it can be recompiled to be inserted where ever it is needed. tricks is an assembler, and it's just a simple command line program. with the new versions of the asm files on the site, it's as easy to use as typing "trasm whatever.asm". after that, whatever.bin will have the hex code you're used to. the fly trap is coded to support two fireballs, but in the provided code it's set up to only fire one. these are the lines that determine the times to throw the fireballs: CMP #$28 BEQ SPIT CMP #$28 BEQ SPIT each 28 can be changed to anything between 0 and 50 to change the time when a fire ball is thrown. replacing them with something like 10 and 40 would make a plant that throws 2 fireballs. it would be possible to make an upside down version, but i can't have all the fun with the coding. maybe this will spark some interest in people doing some more stuff with asm (edited by DMiner on 06-08-06 10:58 PM) |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6449 days Last view: 6294 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. |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6449 days Last view: 6294 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. | |||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6449 days Last view: 6294 days |
| ||
SNN. I just transfered the donut lifts to the new format that i've been using. they're the latest thing i've uploaded to my site.
Tanookirby. the sprites are a constant work in progress. if i work more with the hammer bro, i'd rewrite its movement code to make its jumps better, but for now that's more work than it's worth. The parabeetles can easily be tweaked, but that'll also be work for another day. |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6449 days Last view: 6294 days |
| ||
| peter_ac, hammer.asm and hammer.ips have been reuploaded. bugs 1 and 2 are fixed. 3 is an issue with the original code that handles projectiles, maybe i'll look into that in the future. point 4 i'm not sure how to fix right now. the brick only kills the hammer bro if it hits him a bit off center. this is same behavior that rex has, which is the sprite i used as a base.
edit: i couldn't replicate your problems with the venus fire trap (edited by DMiner on 06-09-06 08:55 PM) |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6449 days Last view: 6294 days |
| ||
| does anybody know much about how blocktool operates. i decided it might not be too difficult to make a similar program for sprites, but i had a few questions first. i would find the answers myself, but i'm not going to be at a computer with smw for about a week. so, here they are:
1. does blocktool insert code into a static location? in other words, does the custom block routine always start at the same SNES location? the alternative would be that blocktool inserts its routine at a place where it finds free space. 2. if the code is put in a static location, what prevents blocktool from overwriting data that might already be there in a hack in progress? 3. if a block uses reloc offsets, does blocktool just insert a modified version of the .bin file? the alternative here would be that blocktool inserts the .bin file unmodified and handles the reloc offsets in its main routine. any technical information would be appreciated, not just stuff related to the questions above. on a unrelated note, i updated my sprite page with a few more goodies. |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6449 days Last view: 6294 days |
| ||
| i'm not promising that i'll make a program, but i am seriously considering it. here's what i had in mind.
my plan is to add support for ~255 custom sprites by using the second extra bit. i know i could use the first extra bit as well and support ~765 sprites, but i wanted to leave this one free to use in sprite code. i think 255 custom sprites should be plenty. i would hijack the code that calls sprite routines. my code would first check if the second extra bit was set. if not, i would return and let the game deal with that sprite like normal. (i would also return if the sprite uses the second extra bit itself). at this point i would know that we're dealing with a custom sprite and i would convert it. the game does many checks with the sprite number, so i would try and avoid this. i would store the sprite number to a ram location (for fun, lets just say $9962,x) and set the original sprite number ($9E,x) to 12 indicating a custom sprite. from then on the custom code could use $9962,x to index a big table. the table would be of fixed length and have 9 bytes per sprite. 6 bytes for sprite properties (basically: tweaker code - asm information) and 3 for the code location. I would set the sprite properties, jump to the code, and be done with the custom routine. there is a little problem using extra bits. they are actually stored in bits 2 and 3 (if the least significant bit is numbered 0) of 14D4,x by the level loading routine (see SNES $02A965). it’s only the sprite code for the goal tape that puts the bits in 187B,x and ANDs them out of 14D4,x. $14D4,x is usually only used for the high byte of the sprite position, and this leads to some interesting consequences. The first is that goal tapes don't work very well on vertical levels. place a regular one on screen 05 and you'll notice it won't show up. this is because 14D4,x = 05 is interpreted as a secret exit (bit 2) on screen 01 (bit 0). using $14D4,x to hold the extra bits also explains all other sprites don't appear if they use them. the extra bits just mess up the high byte of their y position, and they are placed way off sceen. when i planned to use an extra bit i was going to handle them as the goal tape did, but this would make them breakdown on vertical levels. perhaps i could fix this with a hack to the level loading routine. so that's my plan. i'd appreciate some feedback. |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6449 days Last view: 6294 days |
| ||
| thanks... that exactly what i wanted to know. i'll be sure to pop back in if i have any more questions. | |||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6449 days Last view: 6294 days |
| ||
| i thought of another question. if you use blocktool a second time, does everything that you inserted the first time get erased from the rom? if so, any idea how it goes about this? | |||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6449 days Last view: 6294 days |
| ||
| i'm not sure how the block loading routine works. is the whole level loaded once at the begining or does the game just load the parts that are about to come onscreen? either way
dealing with blocks that spawn sprites seems to complicate things greatly. once the sprite was spawned, what would become of the block? i would think that it would need to stay in place. if the sprite wasn't killed and we went back to the original screen, we'd expect it to be respawned. but after the sprite has been killed, then it shouldn't be. there seems to be unnecessary bookkeeping. there's also a couple more issues that i can think of, but it's quite possible i'm thinking about this whole thing wrong on the other hand, i am familiar with how sprites are initialized and loaded into ram when they're about to come onscreen. i know for a fact that it would be very easy to write the snes code to split on the extra bit. that part would be short and sweet. so very easily 00 could indicate a green koopa if the extra bit was clear, and a custom sprite if it were set. i could create the system in my previous post easily in a day. the only semi-difficult or time-consuming thing would be making a program to automatically insert the code. the whole process of finding free space, inserting the .bin, modifying the reloc offsets, erasing the stuff that was inserted in the previous use of the program, etc. i'm without a computer for the next 2-3 days, so i'll catch you guys later. maybe i can get something started when i come back. |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6449 days Last view: 6294 days |
| ||
| I discovered this bug yesterday and have since corrected the error. The problem was in the SUB_GET_Y_DIFF subroutine, and was a result to changing the values of $D3 and $D4. I believe you can fix the bug by copying and pasting the SUB_GET_Y_DIFF routine from the updated code, which you'll find here.
You'll notice that the source is different than the version that I posted in the past. The big change is that all the data is at the very begining of the file. Over the past two days I wrote a program for sprites like block tool (which is working like a charm). It seemed logical to have the data start off the sprite's .bin file, so people could easily change stuff like the tilemap without having to look around for it. |
| Pages: 1 2 3 4 5 |
| Acmlm's Board - I3 Archive - - Posts by mikeyk |
