 |
| 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 - Venus Fire Traps are glitching other sprites |
New poll |  |  |
| Add to favorites | Next newer thread | Next older thread |
| User | Post | ||
SnifflySquirrel Shyguy                  Since: 03-03-06 From: Vermont Last post: 6401 days Last view: 6301 days |
| ||
| I've put DMiner's Venus Fire Traps in my hack, but for some reason they have a tendency to make a sprite near them "invincible" (Mario gets hurt when he tries to stomp on it). It only affects one enemy onscreen, and it isn't 100% guaranteed to happen at any given time, but it shouldn't be happening at all.
I've done some experimentation, and it seems like this glitch affects the sprite that's processed immediately following the Venus Fire Trap (i.e. if the Fire Trap is sprite number 8 onscreen and a red Koopa is sprite 7, the red Koopa becomes invincible). It's possible to lead normally-stompable enemies away from the Fire Trap, and they become stompable again. If you stomp an enemy like a Goomba, then pick it up and carry it back to where the Fire Trap is, the enemy will appear lower than it should be, as seen in this screenshot: 
Furthermore, if I kick the shell I'm holding in this screenshot, it will actually act like it's that low (i.e. it will fall through the ground). I've done some minor tweaking to the Venus Fire Trap code, but I've gone over it carefully and I can't figure out how something like this could happen. Any opinions? |
|||
|
mikeyk Shyguy   Since: 02-22-06 Last post: 6464 days Last view: 6309 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. |
|||
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: 6301 days Last view: 6300 days |
| ||
So, working on 'spritetool'? 
Well, I certainly hope that whatever you're working on pans out, MikeyK. Also, if you need any help, be sure to ask me. I'm definitely going to be using your sprites in an upcoming hack of mine, MikeyK. |
|||
Smallhacker Super Koopa I AM A Group Of Officially Frustrated Younglings, G.O.O.F.Y. MEMBER |
| ||
Originally posted by mikeyk Weeh! How much of the program is done? If (or rather, when) such a program is released, it will really motivate me to get into sprite hacking. Question: Will / does your program use pre-compiled bin/asm files and reloc offsets like blocktool or will it use source code, add a (temporary) "org $blah" line to the start of the file, send it through Tricks and insert the compiled code to the ROM? (Okay, it's probably the first one, but the second one would be really neat in my opinion. No messy reloc offsets and easier to edit.) |
|||
|
SnifflySquirrel Shyguy Since: 03-03-06 From: Vermont Last post: 6401 days Last view: 6301 days |
| ||
I played through the stage three times, and no sign of that annoying glitch. Thanks! 
Originally posted by Smallhacker As someone who prefers to use an assembler for all but the most trivial of ASM hacks, I think it would be really neat to see the latter. I'm pretty sure Tricks is public domain, so it would be okay for him to include a copy along with Sprite Tool. |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6464 days Last view: 6309 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. | |||
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: 6301 days Last view: 6301 days |
| ||
| Either way, I highly suggest you include everything in one file. That is, with Blocktool you need the .bin file, plus a list of what each offset should be, and sometimes an IPS patch. Then you need to add the block to the database manually, set the offsets and info, and apply the patch. It'd be far better if all of this info was contained in the file (either as a block of data in a .bin file, or comments in ASM source), so you can just drop the file into whatever directory it reads them from, open the program, and add it to the ROM.
Also please don't make it keep the files in the same directory as the program itself like Blocktool does, it makes a horrible mess. Put them in their own subdirectory like \Sprites or something. It'd look a lot neater that way. |
|||
Pac Bandit Free Ice Man!  Since: 11-18-05 From: Ireland Rate me Last post: 6301 days Last view: 6300 days |
| ||
Heh, thanks, mikeyk. I thought this was a bit strange too:
 Anyway, lookin' forward to the new program. |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6464 days Last view: 6309 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. |
|||
|
Pac Bandit Free Ice Man! Since: 11-18-05 From: Ireland Rate me Last post: 6301 days Last view: 6300 days |
| ||
Sorry to be picky, but there's just one tiny thing that's bothering me about this sprite.
The Venus Fire Trap is just one pixel lower than it should. Is there any way you could please fix this for the next release? If there will be another release, that is. 
Thanks. (edited by peter_ac on 06-23-06 02:40 PM) |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6464 days Last view: 6309 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 | |||
|
SnifflySquirrel Shyguy Since: 03-03-06 From: Vermont Last post: 6401 days Last view: 6301 days |
| ||
Originally posted by peter_ac If anyone's interested, I found something while trying to fix this. It seems that there's a table of 2-byte pointers at $01:817D (PC $837D) to setup routines for sprites, which are called immediately after the sprite is spawned. By setting the Venus Fire Trap's entry in the table to B0 85 (the same value used by normal Piranha Plants), the plant moved up one pixel and also automatically centered itself on a pipe, removing the need for the plant's code to do that. |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6464 days Last view: 6309 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). |
|||
Knight of Time Red Tektite Since: 11-18-05 From: Canada Last post: 6308 days Last view: 6301 days |
| ||
| Oh wow, a Block Tool for sprites sounds really, really cool.
Could I possibly be one of the first few to be able to try out the program please, mikeyk? I have a funny feeling I may really enjoy using this with my current three world hack (if I get to use it, that is). |
|||
cory21391 Red Cheep-cheep  Since: 04-21-06 From: North Carolina Last post: 6358 days Last view: 6358 days |
| ||
| I'd really like to try it out, as I really, quite honestly, to be truthful, know very little ASM and can't make/use custom sprites. All I really wanted to do with sprites is change some GFX and make a Sub-Boss for my fortresses (Don't like the Reznors). So.. When are you planning to release it/send it out for testing? | |||
ULtI Micro-Goomba Since: 06-20-06 Last post: 6529 days Last view: 6324 days |
| ||
| how do you even apply the hack? I really want to know |
| Add to favorites | Next newer thread | Next older thread |
| Acmlm's Board - I3 Archive - SMW Hacking - Venus Fire Traps are glitching other sprites |
| |
