ASM: Request, help and general discussion

[anonymousbl00dlust]

n00b question time:

how do i change the palette a sprite uses? I know it has to do with that YXCCCPT thing, but actually using it in practice is totally alien to me. If it helps, the sprite currently uses palette D, and I need it to use palette C.

thanks for helping/ignoring me entirely!

[limepie20]

I think the P is for palette. Also, you can use tweaker.

[Cheeseofdoom]

n00b question time:

how do i change the palette a sprite uses? I know it has to do with that YXCCCPT thing, but actually using it in practice is totally alien to me. If it helps, the sprite currently uses palette D, and I need it to use palette C.

thanks for helping/ignoring me entirely!

Before getting into this, can't you just change the palette through the cfg editor/tweaker?

If you need it to change on a trigger or something else, then you have to get into the whole YXCCCPPT thing, which I still have trouble with, but I know how to do. All the sprites in my level change their palette based on the on/off trigger. I had a lot of trial and error when I did it, so I don't exactly know how to explain it...

Each byte of YXCCCPPT is either 1 or zero (binary yo.)

YX is the x and y flip bytes (0= off, 1= on)
CCC is the palette (See below for finding out the numbering system)
PP is priority
T is the graphics page.

Now for the palette, you have to remember you're only working with the sprite palettes. Therefore, instead of being palettes 8-F, they are now 0-7.

If you don't have a binary to hex calculator handy, here's all the palettes in binary:

Code: Select all

Palette 8 - 000
Palette 9 - 001
Palette A - 010
Palette B - 110
Palette C - 100
Palette D - 101
Palette E - 110
Palette F - 111

So these number correspond to the CCC part of the binary number.

So, assuming y and x are 0, and p and t are 1, you would have a number that looks like this for palette C:

• 00010011

Converted to hex, this is 13. This will be the value you need when changing the sprite's property byte.

Now, Terry made me a nice little post that looks like this:

Find the bit in the graphics routine where the YXPPCCCT byte is assigned, it should look something like this-ish:

Code: Select all

	LDA #$09
	ORA $64
	STA $0303,y		; YXPPCCCT property byte

And altering it to this:

Code: Select all

PHY
LDY $14AF ; On/Off switch status
LDA PROPBYTE,y
ORA $64
PLY
STA 303,y

[...Rest of graphics code up to the RTS...]

RTS

PROPBYTE: dcb $1F,$19

Which sort of worked, but was being kind of derpish (the x/y flipping wasn't working correctly [at all .]) I have no idea how the code would look in your case, seeing as I don't know how, when or why you want to change the palette. In that code, I was using !F and 19 as my two YXPPCCCT values. Salvage what you can from it.

I ended up just doing this:

Code: Select all

LDA $15F6,x
ORA #$1F
STA $15F6,x

Which isn't the "proper way to do things," but whatever.

Hope that helps you, it was annoying for me.

[flareblade26]

i wonder, can anyone slow down YCZ's cave story cave in generator so there is only 2-3 blocks on screen at a time and changes the music to number 3D. Thank you!

[Cheeseofdoom]

i wonder, can anyone slow down YCZ's cave story cave in generator so there is only 2-3 blocks on screen at a time and changes the music to number 3D. Thank you!

Ummm.... 3D is my music slot iirc...

http://asmtinfo.co.cc/music

[flareblade26]

..................I had 3 music slots reserved, 3b 3c and 3d.... did you get that within the last month?

[Cheeseofdoom]

..................I had 3 music slots reserved, 3b 3c and 3d.... did you get that within the last month?

I got mine at the beginning of the project pretty much.

I'll post in the request thread about the mix-up. I'm totally fine with giving up my slot and exchanging it for a new one, I just want to make sure we both have a slot.

[raocow]

Now I'm not saying that I'm thinking of making a new level if the collab between anonymousbloodlust and I ever goes anywhere, or something, here, but, in theory, how difficult would it be to control the speed of the 'move the layer two from side to side in a vertical level' dealio?

I'm going to find a use for that marisa world port, even if it means going to such extremes!

[anonymousbl00dlust]

Thank you SO MUCH cheeseofdoom! there is no way I would have ever figured that out myself

Now I'm not saying that I'm thinking of making a new level if the collab between anonymousbloodlust and I ever goes anywhere, or something, here, but, in theory, how difficult would it be to control the speed of the 'move the layer two from side to side in a vertical level' dealio?

I'm going to find a use for that marisa world port, even if it means going to such extremes!

I told you I was making a custom 'layer smash' generator after my moving line guide was done. I'm sure it could be easily modified to work vertically instead of horizontally.

Speaking of which, I'm super not used to working with timers or flags (yes I suck at asm), and I was
hoping I could get some help with said generator. the logic I need to set up is something like this:



(if layer 2 has a y position of #, run the below code, otherwise skip it.)
...
if this is the first frame this code was branched to, run code a
don't do anything for n frames
if this is the nth frame this code was branched to, run code b and change the rise/fall flag



Since this would run periodically in two separate places (rising code and falling code), won't I be constantly resetting the timer? If someone could show me what to do, I'd really appreciate it.

[Cheeseofdoom]

Thank you SO MUCH cheeseofdoom! there is no way I would have ever figured that out myself

Not a problem! I'm surprised as to how un-documented the whole YXCCCPPT thing is, seeing as it's referenced so much in the ram map on SMWC...

[E-Man]

i wonder, can anyone slow down YCZ's cave story cave in generator so there is only 2-3 blocks on screen at a time and changes the music to number 3D. Thank you!

If I remember correctly, you have to change this string of code here in the generator:

Code: Select all

			JSL $01ACF9			; random number generation subroutine
			REP #$20			;\ set new sprite y position
			LDA $148B			; |
			AND #$00FF			; |
			CLC				; |
			ADC $1A				; |
			SEP #$20			; |
			STA $E4,x			; |
			XBA				; |
			STA $14E0,x			;/

The AND #$00FF should be what needs to be changed. Change that to a smaller value (as in something smaller then 0xff) and there should be some sort of decrease in the amount of blocks on screen. That's what it should be anyways, I haven't tested this out at all.

[yoshicookiezeus]

No, that part only determines where on the screen the blocks will spawn (although the comments should say x position, not y). What determines how often is this part right at the start of the code:

Code: Select all

			LDA $14                           ;\ if not yet time to spawn new block,
			AND #$0F                          ; |
			BNE Return                        ;/ return

Change the 0F to something larger (just make sure that it's one less than a power of two, i.e. 1F, 3F, 7F, or FF), and you'll have a longer time between each block.

EDIT: these code tags are not kind to my formatting D:

[Diortem]

I have a question regarding the message box routines. Will there be any more patches in queue to be added that can influence those routines?

For the chest I was thinking of using some of the spare code area left between $05:B1AA - $05:B250, for bringing up the message box using native code as much as possible. The code in that area determines the index of the message stream to display in an unmodified rom, but is superfluous after Lunar Magic inserts a JMP at the beginning to a custom routine FuSoYa(?) made. This shouldn't be an issue, unless someone else's code/patch jumps to that directly, but I doubt that is the case.

[muuma]

Hi, hum, I was just curious actually, but I would like to know if the P-switch song from the first ASMT works with a patch. Because the level music goes on even after we pressed the P-switch. And if there is a patch for it, I would like to use it for my personnal interests please.

[flareblade26]

No, that part only determines where on the screen the blocks will spawn (although the comments should say x position, not y). What determines how often is this part right at the start of the code:

Code: Select all

			LDA $14                           ;\ if not yet time to spawn new block,
			AND #$0F                          ; |
			BNE Return                        ;/ return

Change the 0F to something larger (just make sure that it's one less than a power of two, i.e. 1F, 3F, 7F, or FF), and you'll have a longer time between each block.

EDIT: these code tags are not kind to my formatting D:

Thank you! I'm not so good with asm, so would 5F work?

[yoshicookiezeus]

No, since $60 is not a power of 2. You'll need to use one of the values I posted. (although I could easily set the thing up to run on a timer instead, so that you could use any delay between blocks)

[Cheeseofdoom]

Quick question.

Would there be a way to disable all sound effects, or even just specific channels through asm?

bigEdit:

I have a level that consists of a lot of the yellow flip blocks. I would like to add a displayable counter to the screen that displays the number of blocks that the player has broken.

This is easy enough on the asm end for someone that has a bit more time than me right now.

1. If player is spin jumping, check their powerup status; if not small branch to shatter routine.
2. Increase empty ram. The "target block" on SMWC uses $0B44.
3. Run the shatter routine (JSL $028663,) and presumably erase the block (I wouldn't think the shatter routine would cover this.) I'm not sure if you have to do anything else here.

Now the hard(er) part:

4. Draw the tiles based on the ram you increased.

This is the part I'm not sure of, there's a patch that displays the on/off status in the status bar on SMWC if whoever is attempting this needs a reference.

Of course, none of this is needed for most the people that are experienced with asm here, but I figured I might as well help out anyone else that may want to try, and perhaps learn something from whoever does it.

[yoshicookiezeus]

"Yellow flip blocks" as in turn blocks? Then we're going to need the Bounce Block Unrestrictor patch (or something like that), or we'll have the custom turn block reverting to the normal one after you hit it from below. (Also I'm not entirely sure how the game handles the spinning turn block turning back into the normal one, but I would assume that it is handled by the bounce block sprite.)

Also, displaying stuff on the status bar is easy: just write the tile you wish to display to the appropriate part of the status bar tilemap.

[yoshicookiezeus]

Apologies for the double post, but would anyone mind if I went through the current blocks database, replacing the older blocks with new ones that have all the proper offsets? Also would replacing the old ice blocks with Ersanio's ones that melt instead of shattering (and erases the fireball instead of letting it keep bouncing) break anything?

also why would you have a bin folder if you place all the .bin blocks in the asm folder instead

[raocow]

Go crazy, man. That sounds like something we could definitely use!

[yoshicookiezeus]

While I'm at it, any objections to me adapting the various conveyor/wind blocks to affect sprites as well as Demo?

[raocow]

Hmm, that I don't know if it would affect any of the existing levels. Normally I'd be all 'sure', but I don't know about that particular thing.

[ProfessorDemetri]

Spoiler for raocow's sake.

Zeus:

As far as I've seen, there aren't any wind levels yet, so I don't see this as being a problem..
I'm just concerned about room. >.>

[yoshicookiezeus]

...room? All the added code wouldn't take up more than at the most a hundred bytes.

[yoshicookiezeus]

Done.

BTSD stuff.zip

It's been a while since I last disassembled stuff manually

(36.63 KiB) Downloaded 105 times

Contains:
- an asm folder to replace the old one, with all the fixed blocks (I cleared out the .bin ones)
- .dbk and .dsc files, to save whoever is in charge of inserting stuff the trouble of updating BTSD's block database themselves
- new Map16 files for page 4, fixing a couple of oddities I discovered

Please tell me if anything breaks horribly or generally doesn't work as it should.

Also, might I recommend that the Slow and Very Slow movement blocks for the up/down directions are removed? Their "move player every second/fourth frame" effect make for some very jerky movement, as I discovered during my testing.