It actually is the one at $009250. SMW only calls the routine on power-on, but leaves the HDMA in channel 7 so it continues to be used. (if you ever write another DMA to channel 7, it ends up getting bombed)
To clarify, here's the table it writes, in a more clear format:
DMAWindowData: ;$009277 | Windowing DMA settings and data, stored to $4370-$4374.
db $41,$26 ; Translation: write data pointed to by $00927C to $2126/$2127 (window left/right positions).
DATA_00927C ; $00927C | Pointers to the windowing data in RAM.
db $F0 : dw $04A0
db $F0 : dw $0580
I'd like to be able to use multiple types of HDMA in an area, but simply copy-pasting the code together in one document turns up an error. I'm not sure how the code should be modified to fit them all in, but simply commenting out the offending errors will result in a game crash, so I'm certain that's not the solution.
I'm trying to insert foreground, background, and wavy effects, and they do each use a separate channel.
AND keep in mind that foreground and background HDMAs are technically the same type of HDMA, it's just that foreground HDMAs mess with colour maths (read: simple transparency) and priority which gives the illusion that the HDMA applies to the foreground even though it's still on the background and the foreground (save for some sprites) is transparent to it.
Wavy HDMA and gradients work together fine, though, due to affecting different things (one is the background colour, the other the scrolling of a background).
Unless you change its behavior in the code, a block will act like the tile it's set to act like in Lunar Magic. Check the "Act as" field in the Map16 editor - 130 is solid and 25 is passable, just to name two. (Those are tile numbers - tile 130 is the cement block, tile 025 is what fills empty space, and so on.)
If you want to change the setting in the block's code (which doesn't seem necessary here), try something like this:
LDY #$01 ; high byte of map16 tile number (iirc)
LDA #$30 ; low byte of map16 tile number (iirc)
STA $1693 ; this would make the block act like tile 130 no matter what LM says
I found here a way to disable all controls in a level, but I think I'm missing something in the code.
I did this, which I think would be ok if I used Asar to apply it to the whole hack:
But I want it in ONE level and UberASM tells me I'm "missing load/init/maint/nmi label". I know UberASM has some particular things to put in it, which I don't really know.
Do I just need to get rid off hearder and lorom and add RTL at the end? Or add maint: or init: at the beginning? Or something else?
I am trying to convert an old 32x32 custom block that shatters to use the better optimized ChangeMap16 routine from G.P.S., but I don't get it to work propperly. Either it only shatters (breaks) 1 of the 4 blocks or it instantly crashes the game.
The old routine would use A instead of X to load the tile number.
According to the routine in GPS:
; REP #$10
; LDX #!block_number
; SEP #$10
I tried doing something similar later, but I believe it didn't work because I used PHP and PHX and then PLX and PLP respectively, and I didn't tried doing the opposite way (PHX/PHP and PLP/PLX). Looks like you have to preserve X before preserving processor status
However, even with that, you probably won't be able to make it appear in front of other sprites, only other layers. Sprite order is handled by the OAM indices the sprite tiles actually end up in; the original boo ring uses the cluster sprite slots (in the $0200 block) and hence appears in front of most sprites, but this custom sprite uses the standard sprite slots (in the $0300 block) and won't appear below sprites using those lower slots. Professional frame-by-frame time wizard. YouTube - Twitter - SMW Glitch List - SMW Randomizer
I am also having some issues with OAM index in relation to sprites > layers.
I'm trying to get the Urchin Disassembly to have low priority and go behind layer 1 (similar to how pipe piranha plants do).
I tried adding Thomas' code above into the sprite (in varying locations) with no luck. I also looked at how piranha plants and lakitu handle priority but that left me lost.
It seems in the Urchin's case the following code handles some of it's priority, but I don't know how to modify this sprite to go behind layer 1.
What you posted is the call to the "finish OAM write" routine, which needs to be at the end of every sprite's GFX routine and (IIRC) sets tile sizes (LDY #$02 means the sprite uses 16x16 tiles, LDA #$04 means it has five tiles).
What you need to look for is the properties byte, which is usually stored to $0303,y (or apparently $04 in the above case). In the Urchin disassembly these bytes come from the table named "TileProp", so all you should need to do is edit the numbers there.
They're in YXPPCCCT format, which means that when you read the number in binary, each bit corresponds to a setting. The first number in the disassembly is $37, which is 00110111 in binary and gives us the following settings:
Y and X stand for "Y flip" and "X flip", and they're both 0, so this tile isn't flipped.
CCC stands for the palette to use, and it's 011, so this tile uses palette B.
T stands for "use SP1/SP2 or SP3/SP4", and it's 1, so this tile comes from SP3/SP4.
The bits you care about are PP, standing for "priority". They can be 00, 01, 10 or 11 (in order from lowest to highest), and here they're 11, which gives this tile the highest priority.
To give the tile the lowest priority instead, change those bits to 00. If you do that and read the resulting number in Hex, you get $07, so that's what you should replace the $37 with. Do the same with the rest of the entries in the TileProp table and you should be good to go.
(as Thomas noted, though, that will only affect priority against layers, not other sprites).