| User | Post |
HyperLamer
Posts: 162/8210 |
1) That's what I kinda thought; though I guess that ruins my idea of putting more various objects on Layer 3 to follow Mario and such. That is unless it only does that when you've got Layer 3 Windows on...
2) Oh yeah, doh.  Though I'd have to switch to the non-darkened palettes when I illuminate the area... How's this HDMA work exactly?  |
BMF98567
Posts: 58/1261 |
The game uses HDMA to split layer 3 directly underneath the status bar; that's why the lower part can scroll independently and have lower priority.
To control the brightness of layer 2, just change the palette entry used in the dark area via an ASM hack. |
HyperLamer
Posts: 149/8210 |
Hmm, I know this is a semi-old thread, but I have another question...
How's this work? It looks alright, but look closer. Here we see layer 3 in the BG (the windows), layer 1 as object (the floor), layer 2 presumably as light beams in front of that, and ...layer 3 in front of them all (the scorebar)?  But L3's the background windows, how can it be in front?
Also, I wanted to use colour subtraction and layer 2 to make a very dark level in which there would be a small light patch around Mario, and the rest way dark (though it'd light up in some places by turning layer 2 off). Is there a way to control the brightness of the area that would be in the dark?
And one more. What address is the real beginning of the exit tables in the level? I've seen like 3 claimed to be it and I dunno which to write to.  |
BMF98567
Posts: 41/1261 |
1) Yes. All 32 screens are rendered in memory, regardless of the "number of screens" setting in the header (AFAIK, it's *only* read by the scrolling routine to determine where to stop).
2) Immediately after the last layer 1 page, I believe.
4) You mean the block's RAM address? Of course, otherwise Map16-changing blocks wouldn't work. I'm not entirely sure how to do it myself, though...
6) Yes.
7) Yes. A few of them are listed in the old memory locations thread. (Did you know $1DF9-$1DFC are just mirrors of SPC700 ports? I think all but one are directly copied during V-blank.)
8) Just what it says: cuts the color data in half, essentially cutting the image's brightness in half. |
Kenny3900
Posts: 2/9 |
1) Yes, AFAIK; But since we can't go past the unused pages, we can't deduce it's true or not (cannot see visible effects)
2) Page 10, i.e. 7_C800 + 10 * 1A0 = 7_E200 (_ = E for low, F for hi part)
3) Haven't examined, but I think it's left-to-right then up-to-down.
4 and up) dunno |
Atma X
Posts: 23/801 |
No, the Map 16 data (16x16 block data) always has Pages 0-1F availible, no matter how much of the Level's screens you use.
(That's what you wanted to know, right?) |
HyperLamer
Posts: 105/8210 |
I'm talking about in memory. In a horizontal level, the first byte is the top left corner, and it goes from there to the top right corner, then the next byte is one block down from the top left, and so on. I wanted to know if in a vertical level it still works this way, or if it's laid out top to bottom or some such craziness.
And I think you misunderstood #1. As you know the levels are 0x1F (or was it 0x20?) screens long (assuming layer 2 is a BG image). What I'm asking is if you only use up to say screen 4, does the Map16 data in RAM still contain the screens up to 0x1F or just up to 4? |
Alaric
Posts: 5/72 |
Ehh.. Atma.. i think he's talking about the Map16 data in the level layout for #1, etc. |
Atma X
Posts: 21/801 |
It doesn't matter if it's a horizontal level, or a vertical level, the order doesn't change at all for any reason. (BTW, The 16x16 Tiles always ascend in a horizontal order, you can also highlight a 16x16 Tile with your cursor to look at the it's Map 16 #, and then look at the next Tile's # to find out its' order)
Or are you talking about the way it's placed in the level layout?
Oh, and the BG Map 16 data starts on Page 10, and goes to Page 1F
Re: 1) Does the Map16 data contain the entire 0x1F screens, even if a level doesn't use them all?
Yes. All of the levels can use any FG Tile in any of the screens (FG 0-F, BG 10-1F, although the Background can only use 1 Map 16 Page per level, push "Page Up or Page Down" in the Background editor to set whice Map 16 # the Background uses for that level). |
Alastor the Stylish
Posts: 184/7620 |
Why would LM bother to change it? Seems kinda dumb to me. |
HyperLamer
Posts: 96/8210 |
Originally posted by blackhole89
Find out yourself. Make a horizontal level, place some objects, then turn it into vertical and have a look where which objects have landed.
But how do I know if LM's moved them or what? Besides, I would think LM deals with raw level data where as the Map16 is processed data, so it doesn't exactly help. |
blackhole89
Posts: 17/971 |
6) - Yes. But not by the SNES but rather hardcoded in SMW. Way better that way.
3) - Find out yourself. Make a horizontal level, place some objects, then turn it into vertical and have a look where which objects have landed.
GreetZ
Blacky. |
HyperLamer
Posts: 95/8210 |
Just wondering about a few things related to stuff in the game's memory.
1) Does the Map16 data contain the entire 0x1F screens, even if a level doesn't use them all?
2) In a layer 2 object level, where's layer 2's Map16 start?
3) Does Map16 still go from left to right, top to bottom in a vertical level?
4) Is there some code one can use or subroutine that can be called to determine the Map16 address of a block from within that block's code?
5) Where's the background's tilemap?
6) Is the in-memory CGADSUB ($40) set back to default when you leave a level? I played with it in ZSnes and all I can say is .
7) Are there in-RAM copies of other registers?
8) Just WTF does the "1/2 Colour Data" bit of CGADSUB do?
[edit] To clarify, all of these are relating to RAM addresses. In #2 for example, I'm asking where in RAM the Layer 2 Map16 starts. |
labmaster
