Custom Scrolling Sky
Release Date: Nov 04, 2018
Author: Amoeba
Type: Assembly
Rating: Pending
Links:
[download] .asm file (31 downloads)
Game: SM
Description
Custom Scrolling Sky by Ameoba

This will let you have as many different versions of scrolling sky as you have rooms. Just edit layer 2 for a room in SMART or SMILE and this will make the first column of screens load in as scrolling sky. The bands' sizes and speeds can be edited in asm below. Select which table to use by setting the value of the first tile in the layer 2. All the edits should be right in that first section on tables

Update 1: Doesn't cause the game to hang when loading the game in a room with scrolling sky.

Update 2: Doesn't cause VRAM corruption when loading the game in a room with scrolling sky.

Update 5: I skipped updating a few times. This version is much faster and fixes a couple more bugs. This version can be seen in action in Subversion.

Update 6: Fixed a bug with extra tall bands that wasn't handled correctly. Fixed interaction with using XRay OOB when it corrupts memory and overwrite the index being used to look up the table by making a copy of it somewhere safer.
Media
Screenshot Screenshot
Ratings and Reviews
By MetroidNerd#9001 on Jul 02, 2019 (Star Star Star Star Star )
A bit tough to get to work before you figure it out, but once you get it, it is the most comprehensive scrolling sky fix out there. Very good, very useful.
By dewhi100 on Feb 29, 2024 (Star Star Star Star Star )
This is the one you want. Does everything the old ones do, while being infinitely flexible, and not broken.

Quick Start guide:

Add a new table with a fun name after the "ScrollingSkySectionTable_002" one. Copy the first and last lines of one of the existing tables to give yourself a baseline.
That table's name goes on the end of the list under "ScrollingSkySectionTable_List:" a little ways above. You pick which table a room uses by using the room editor. The very first layer2 tile (in the top-left corner of the room) is not part of your pretty scrolling sky- it is an instruction telling the code which table to use. As a result, it will be an ugly door cap tile from the CRE. Tile 0 (the closed PB door corner) will tell the code to run table 0 (The space efficient OG scrolling) for example. Be wary of your ugly tile showing if you aren't hiding the top of your room (if you have a ceiling door for example).

THIS IS IMPORTANT:
Table 0 is the first table. The SECOND table is TABLE 02. The indices go up by 2- there are only even table indices. The tile you want for your new table will therefore be index 04 (the first green door cap tile).

And while you're in the editor, set the room state's init ASM to 91C9 and its Main ASM to C116. If you apply the ASM now, you can also Quickmet to get an idea of what the patch does.

Right now, the whole room will scroll at the same speed. Because each line in the table (besides the last one) is the start of a "band" that scrolls together. You add a new line for every time you want a new band with a new speed (including 0, stationary). The first DW on a line tells where those bands' tops are. DW $0340 would be screen 3 tile 4 pixel 0 for example.

In the DD, you can ignore the first four 0s. In theory they are subpixel speed but you don't need them. Use the existing tables for a reference of the speeds you want stuff to move.

OF NOTE: You see those "!repeated" DDs? They're defined as $00000000 but don't use them for speeds of 0 (although they might work for that). Instead, use them whenever you're setting a band to a speed that's already being used by a different band in the table. If you want something to be stationary, manually write "$00000000" once, then for other stationary bands further down use the !repeated.

How does the code know which bands' speed to repeat? That's where the last DW comes in. It points to RAM where you are storing the speeds from the DD section. It's RAM specifically set aside for scrolling sky even in vanilla, and there's more than any sane person would need. It's split into four-byte chunks (notice the DD speed has four bytes), so after $9F80 will come $9F84. The optimized way to use that RAM is to store a bunch of unique speed values there and refer to specific speeds multiple times as needed.

Think of it this way: every time you use a DD with a $ and a new speed, you are writing to RAM. You need to put a new, unused address (your first one will be $9F84) in the DW. Every time you use a DD with a !repeated, you are reading from the RAM and need to put an already used address (of the speed you are repeating) in the DW. Again, if you are insane, don't be constrained by that thinking because it's not technically correct, but for 99% of people using the patch it's helpful to think this way.

Hope this helps.

You must login to rate this resource