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. |
User | Post |
JaSp Posts: 66/89 |
Ok so I finally found out how to make the game think that Mario is standing, but I need to know if there might be a way to get the block's vertical position on which Mario is ? It would avoid me to create several different custom blocks routines, according to their position in the level, that write absolute values to Mario's vertical position. |
HyperHacker Posts: 2558/5072 |
$94 and $96 should be Mario's pixel-specific X and Y position in 16 bits. Were you maybe checking the high byte? |
JaSp Posts: 64/89 |
Well I tried several addresses related to mario's Y position, and I came up with different cases. Usually, either the whole block acts like a solid block, either it acts as a blank one. It also happenend to have a blank block that would act like a solid one when Mario was ducking. Moreover, it was screwing up when approaching other blocks and such, resulting in killing Mario sometimes...
I've even tried to directly write to the Y position, but then Mario can't walk and well, it's not convenient at all anyway. I'm still trying to figure out how slopes work, so far I haven't found anything interesting, it seems that $91 is used as a buffer that then writes to $96 (Mario's Y position, the one that change his position when you change its value), but changing $91 doesn't do anything and removing the opcodes related make strange things (Mario kind of bounces on the slopes...) I'll keep this updated as soon as I find something interesting. |
Sukasa Posts: 1118/2068 |
Well... SMW MUST store mario's pixel-by-pixel X/Y locations somewhere.
Anyways, what does it do, when you say it fails? |
JaSp Posts: 62/89 |
As expected, it doesn't work ; this way of determining collision (writing to $1693) doesn't seem to allow pixel-perfect precision but only 16*16 block precision. I'll try to take a look at how slopes and the like work. |
BMF54123 Posts: 464/876 |
I have a feeling this method would either kill Mario or push him out of the block.
Perhaps we need to study how slopes work... |
Smallhacker Posts: 635/832 |
You're supposed to use the absolute Y coordinate, check if bit 3 is set, make it solid if it is, otherwise not solid. |
JaSp Posts: 61/89 |
Is there a RAM address for Mario's Y relative position to the block (because I can't find one on SMWC) or should I use the absolute one (i.e. I'd have to create several custom blocks according to their position in the level, that wouldn't be very neat...) ?
(sorry for asking so many questions, but well, if someone has a clue about it it would be way quicker than having to research it on my own) |
Sukasa Posts: 1092/2068 |
whoops, I forgot to mention that bit. thanks SH. |
Smallhacker Posts: 633/832 |
Mario's Y position. (If there's two such bytes, the lower byte is the correct one.) |
JaSp Posts: 59/89 |
I'm kind of confused here...I'd have to check for bit 3 of which address ? |
Sukasa Posts: 1090/2068 |
Shouldn't be too hard... check to see if bit 3 ($08) is set, and if so act like a cement block, otherwise act like open space from the top and sides, and a cement block from the bottom. |
JaSp Posts: 57/89 |
Well, since I've been searching without having found anything successful yet, I'm simply asking it here :
Is there a way to get block which have, for example, the top-two 8*8 tiles as blank and the bottom ones as cement ? So basically, I'd like to move the collision detection point from 8 pixels off, for a particulary side of the block (top, bottom, left or right). I've been trying using custom block, playing with the below, above and sides offsets but they turn out not to be what I was thinking... Another question, what exactly are the reloc offsets in blocktool ? I didn't manage to find out how they work in the already made custom blocks using them. Thanks for your help |