Quote:
I need help with some stupid confusing color setup that deals with the Lakitu's palette.
$686b is the start of the palette data for enemies. They are assigned their palette by the numbers given.
from the start it's:
01 02 03 02 01 01 03 03 03 01 01 02 02 21 01 02 01 01 02 FF 02 02 01 01 02 02 02
And at $687c is the Lakitu palette, which is 01. I changed it to 03.
However in the picture I showed you, the corners seem to not change.
I think it's caused by some gay routine for how it mirrors the lakitu cloud, but I don't get it. It's assigned in a confusing way. I'm not too good at ASM, but as how I editted this and all I'm pretty good at finding small values.
I don't understand how it's assigned. Can someone please help?
There's an SMB Disassembly and all but like I said I'm not good with ASM besides maybe using it as a refference of what to edit.
I'm one of those "wing it" type of guys.
Please help. Pretty please?
I posted this on acmlm boards originally. I wanted to post here too since ASM is pretty tightly known here. I'm sure you guys can help. I'm trying to make the whole Lakitu sprite's palette change but it's just not working.
I wish doppelganger was here to help.
Are you certain of the palette format? And also, try to look in the disassembly for a sprite drawing routine; that will probably give you some more answers.
And also, I recommend reading up on ASM, since it's very simple once you get the hang of it. Sorry, I don't mean to sound like a turd if I do...
I know that it's because of some routine that deals with the cloud sprite being horizontally flipped. I know the problem I just don't know where to locate it and fix it.
Maybe I'll point out some coding and post it on here as possibilities to what is causing it.
I know it's a small error but I'm working on making an SMB1 hack that will end the "SMB1 with SMB3 graphics" frenzy.
In my hack I got everything pretty much straight-down into a SMB3 scenereo, backgrounds are 'cactus' mountains and all, the bricks are just like SMB3 bricks, including the "hit" sprite of the brick, both in surface and underground. The colors are all adapted to the most correct possible palette, with some exceptions, like how koopas don't have that overlay sprite for their shell color. Mario's animation is completely as possible, correctly adapted into an SMB3 format without any bad sprite postures. The islands/mushrooms are platforms as seen on SMB3's level 1-6.
Pretty much all blemishes that any other SMB1 to 3 adaption is gone to give you the crisp SMB3 look in SMB1's game.
CKY-2K/Clay Man wrote:
I know it's a small error but I'm working on making an SMB1 hack that will end the "SMB1 with SMB3 graphics" frenzy.
Then people will just shift to the "SMB3 engine with SMB1 levels" frenzy.
Well, if you have a disassembly, you should try and located "$4014", because that will tell you if they use Sprite OAM. And you will then be able to see what page they store in, and then locate writes to that area of memory. If they work with $2003/$2004, I don't know too much about that; I always just dedicate a page of RAM to OAM.
Searching for that will probably find you some answers.
CheckToMirrorLakitu:
lda $ef ;check for lakitu enemy object
cmp #Lakitu
bne CheckToMirrorJSpring ;branch if not found
lda VerticalFlipFlag
bne NVFLak ;branch if vertical flip flag not set
lda Sprite_Attributes+16,y ;save vertical flip and palette bits
and #%10000001 ;in third row left sprite
sta Sprite_Attributes+16,y
lda Sprite_Attributes+20,y ;set horizontal flip and palette bits
ora #%01000001 ;in third row right sprite
sta Sprite_Attributes+20,y
ldx FrenzyEnemyTimer ;check timer
cpx #$10
bcs SprObjectOffscrChk ;branch if timer has not reached a certain range
sta Sprite_Attributes+12,y ;otherwise set same for second row right sprite
and #%10000001
sta Sprite_Attributes+8,y ;preserve vertical flip and palette bits for left sprite
bcc SprObjectOffscrChk ;unconditional branch
NVFLak: lda Sprite_Attributes,y ;get first row left sprite attributes
and #%10000001
sta Sprite_Attributes,y ;save vertical flip and palette bits
lda Sprite_Attributes+4,y ;get first row right sprite attributes
ora #%01000001 ;set horizontal flip and palette bits
sta Sprite_Attributes+4,y ;note that vertical flip is left as-is[/code]
CKY-2K/Clay Man wrote:
Code:
lda VerticalFlipFlag
bne NVFLak ;branch if vertical flip flag not set
Did you make these names up? Because if the VerticalFlipFlag IS set, it will branch, because it Branches when Not Equal to zero. So if that byte IS one, or anything but zero, it will branch.
It was from dropgangler's SMB disassembly. However the pure disassembly that never-obsolete gave me on the acmlm let me know where to locate the code a lot easier, and I found out replacing all the "$29 $81" to "$29 $83" would fix my problem.
Not really an ASM person but I assume $81 means to flip the tile and assign it palette $01, so I changed it to $83.
Oh crap. Thanks for catching that. I guess I missed it.
doppelganger wrote:
Oh crap. Thanks for catching that. I guess I missed it.
Huh? No you had it labeled it's just that I rather hex edit it than go through ASM.
No, I was referring to what Celius pointed out in his last post to this thread.
No Problem. However, it's possible SMB1 checks to see if the flag is clear to do a flip. In that case, it would be correct, but a few comments would need to be changed.