 |
| 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: 6462 days Last view: 6307 days |
| ||
| The program is done... done in the sense that it's written and working. As it is, it uses precompiled .bin files and reloc offsets. I will look into changing it to use Tricks, because there are quite a few offsets, and I agree that making note of them is a pain. Right now it's a command line utility, but I'll wrap it up in a GUI at some point. In the next few days I'll let a couple people try it out, so I can get some feedback. More info later. | |||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
Smallhacker, thanks for the idea of having the program use tricks. I'm happy to report that I just got sprite tool running on asm source code rather than binary files. No more messy reloc offsets  . Right now there are two files per sprite (for example, venus.asm and venus.cfg). The cfg file specifies the 6 property bytes, the name of the asm file, and a couple other things. the asm file is just the source code that gets assembled. Both files are put in a subdirectory. The user only has to specify the name of the cfg that he wants to use for a sprite. |
|||
|
mikeyk Shyguy  Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
| now that the program just deals with asm code, that's an easy fix... done. i'll probably get the first version of the program out to some people this weekend, so it won't be long now | |||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
| Sniffly, sprite tool takes advantage of the data that you just posted. If you take a look at the updated venus code that i posted in this thread, you'll see that the initialization code is separate than the main code . Here's a bit more info on that area of the ROM.
I think the best part of my findings was the realization that a pointer table always follows a JSL $0086DF instruction (22 DF 86 00). |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
| while some people make a case for new comers to ask whatever come to their mind, i think it's easy to lurk for a while and get a sense for what's appropriate. i think it's too common for noobs to look past available resources... especially the lunar magic help file. it's a great source for almost everything a newbie could need. to think of the time that fu put into it only for everyone to ignore it is disheartening.
it's easy to judge everyone at being noobs at some point, but that doesn't mean the board should be crowded with the same questions. i remember reading tons of posts before i ever imagined asking a silly question. you can take a look at my first post ever here (nearly two years now, but fitting that it's about sprite editing). maybe there has been a decline in hacks... it has been awhile since i've seen a screenshots thread, but i don't think that it's something permanent. i hope that we can see some quality work from the smw hacking community. |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
| i like the creativity, and i will take at your code after i get a nap.
when you say your code doesn't work, what exactly do you mean? does it crash the rom? does it make it to all the phases, but not act properly at a certain one? is it getting caught a certain phase and not progressing? tracing is your friend there, and any specifics would help someone who didn't write the code themself. this kind of thing would be much easier to debug if you have an idea of where it's breaking, and also if you're willing to share a rom with the code already inserted. for now i strongly recommend that you start working with an assembler (http://www.programmersheaven.com/zone8/cat715/13206.htm), for someone who understands, it should be a breeze to learn and it will make asm hacking a million times easier. not having to update every branch anytime you make a change will take away any reluctance you have to change things. |
|||
|
mikeyk Shyguy  Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
| I didn't check out the code before Cirvante's post, but that would be a definite problem. If using a RAM address >= 8000, you definitely need to use long addressing. | |||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
The major part of sprite tool is done, and I have some people testing it at the moment. Here's some screens of some sprites that are included...
               
There's a few more that aren't pictured, but these are the sprites that will probably be included in the first public release. To save a few questions, that should be in a few weeks. |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
| The donut lifts are blocks that turn into sprites. That's how they've been since I released the code here http://home.comcast.net/~dkaminski/disasm/dis.html, but now they're significantly easier to insert with sprite tool. | |||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
| ttyyuu, heck of a bump for no reason, but since it's up now...
Sprite tool has a couple custom sprites that react when all enemies are killed. one triggers the level ending (normal or secret). Another generates a key or keyhole. This makes is simple to make any room a boss room. |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
| i'll post responses to a few other posts later, but the one from Bloodstar got me thinking. Earlier I had the thought to make a giant ? with blocktool, and I was wondering why no one has ever made them. I guess they wouldn't bounce up, but it seems like something that would've been done by now. | |||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
| thanks for all the praise guys. sprite tool will be released soon in one form or another, just so it will never be one of those projects that dies in a corner. people wont have to come back months later and wonder what happened to it. i will at least release what the testers have been working with. as is it may not have the best interface, but it's not a hard one to use. that being said, i went back to the start of the thread and addressed all the questions that haven't been answered.
tristis: i don't understand everything in the rom, but i do have a good understanding of smw's sprite ram addresses and routines. if you have those and a talent for programing in assembly, sprite hacking is something that can come pretty easily. rain main: sprites not pictured: -missile bill -poison mushroom -one that will trigger the level end when all enemies are killed -one that will generate a key or keyhole when all enemies are killed kins: the sprites are placed in LM using the Add Sprite Manual dialog. (found by hitting INS while in sprite mode.) You use the extra bits to indicate a custom sprite. surlent: the roto discs are almost a copy of the ball and chain. as for the donut lift... the block turns into a sprite. the sprite counts the number of frames mario has been on it. if it reaches a threshold it falls down, never to be seen again. if mario gets off before the all begins, the sprite changes back into a block. they act just as they do in smb3 for other enemies... as blocks they can walk on them as normal, but when they are sprites they'll be like air. rain main: you can certainly create your own sprites. as peter said, theres a option of just inserting tweaked versions of existing sprites. as for true custom sprites, i will include a few tutorials with the release. they'll let you get your feet wet amd make some simple sprites, but you'll need to be confident with asm. there's MUCH more to worry about with sprites than there are for blocks. sniffly: the problem with the roto disc and yoshi has been noted but not fixed. i said earlier the roto disc was almost a copy of the ball and chain. turns out the original ball and chain had this same issue. i will certainly try to iron out this detail cirvante: no, i will not marry you. haha cpubasic13: yes... custom bosses. that was fun. davros: it's possible to have new sprites while keeping the old ones because of the extra bits mentioned above. if they are set, use the custom handler. if not, use the regular handler. knight of time: the sledge brother does cause the ground to shake and stun mario, but it's not perfect. mario can't move, but he can change directions, and if you press jump the sound effect will still play. i couldn't find any ram address that would freeze mario. someguy: according to http://www.themushroomkingdom.net/mariopedia/ the crab's name is... crab. it just walks at mario like a goomba. when it is stomped on, it gets mad and tries to flee (changes direction and increases its speed.) it's killed if stomped on again. spel werdz rite: i think the giant ? could be made with blocktool. i tried out a simplified version of what i was thinking: 
on the left, the yellow block is the custom block. the blue ones are just the standard "acts like 130". hitting the yellow block from below causes the screen on the left. maybe the giant ? would have to be made up of 4 custom blocks, but i think this shows it's doable. everyone that wanted a screenshot and explanation of the program: 
in the current state, all the average user has to do is make a text file and type in two file names. the text file is the sprite list, just pairs of sprite numbers and .cfg files (seen in the screen shot). The .cfg files are meant to be made by the people who code the sprites. The .cfg file has the 6 sprite property (tweaker) bytes along with the name of the .asm file that is to be used. This allows different version of sprites to be created from the same .asm file. for instance, the shy guy is ridable with one set of property bytes, and stompable with another. everything else seemed to be some sort of sprite request. right now i'm concentrating on other things, so i'm not working on any new ones. in the begining, you'll just have to be happy with the first 20+... that shouldn't be too tall of a request. |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
| someguy:
i forgot to talk about the extended sprites. there's nothing in sprite tool to edit these. if you're interested in doing something manually, i can at least provide some information. 0x11D2B is the start location of the pointer table for the extended sprites (13 entries, 2 bytes a piece). check the ram list (starting at 7E170B) at smw central, i submitted the ram addresses that they use. sukasa: thanks, i'll take a look for it. i'll pm you once i give it a try. |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
| there is no way around that one. only the first two pages of 8x8 tiles can be used for blocks. the second two pages are graphics for sprites. | |||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
| is there a set of question blocks that generate an item and then go to the next map16 tile instead of the used block? | |||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
| the items i'd eventually want are mushroom/flower, mushroom/feather, star, coin, multiple coins, 1 up, and pow. if some are more difficult than others, it's not too big of a deal | |||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
| i'm working on the tutorials now. i'm trying to be as clear as possible, but i have a feeling they're going to have to be a work in progress on after i get them out.
diagonal shooters will not be included in the first release of sprite tool. right now you can only add standard sprites. generators and things will likely come a bit later. if i did release something like diagonal shooters now, they would take up a sprite slot. so if you had a few on screen, then there wouldn't be room for many other sprites (like the bullets they would be shooting). |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
| I've gotten pretty caught up with other things lately, so I wanted to get a release out in case I fall off the face of the Earth for awhile. Get the program
here. Read the readme, and see if you can't get my sprites running around in your roms. If anyone is daring enough to try sprite hacking, you're gonna need to be good with asm. take a look at the tutorials. If things are unclear help me make them better. Have fun. (edited by mikeyk on 07-22-06 01:46 AM) (edited by mikeyk on 07-30-06 11:05 PM) |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
| ghetto: Are you using a cfg file from a test version? I changed the format a bit. There are now two extra property bytes in between the Tweaker bytes and the filename. Edit: The only sprites that use the extra bytes so far are the ridable sprites (beezo, shy_guy, snift, para_beetle) and roto_disc2. Just set them both to 00 for other sprites.
Another thing to note is that cfg and asm files cannot have spaces in their filenames. (edited by mikeyk on 07-15-06 12:09 PM) |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6462 days Last view: 6307 days |
| ||
| kario: there are two things you should be typing into sprite tool itself: the rom name and sprite list. sprites.txt in the main directory is an example of a sprite list. read the readme for more information. |
| Pages: 1 2 3 4 5 |
| Acmlm's Board - I3 Archive - - Posts by mikeyk |
