Custom message/info blocks are usually limited to a specific level, or a few levels if you make use of buttons pressed or something similar. This block on the other hand can load messages 1 and 2 from any main level (OW-enterable) in the game. Like the vanilla info box sprite, the block determines whether it displays message 1 or 2 depending on its X position.
The catch? The block gets the translevel value from the low byte of its map16 value. This means to make use of every level message, you'll need to reserve a range of xx00-xx5F (ideally the same page) of your map16 for the block. You can make use of GPS's range feature in the list.txt to quickly insert the block into the necessary map16 values. That's still a lot of saved hassle compared to copying and editing asm files for each level you want to fetch messages from!
Includes "ExGFX" which is the vanilla info box graphic, and a palette file which slightly modifies palette row 7.
Credit is unnecessary but appreciated.
Screenshots:
Rejected due to compromising sublevel functionality.
This block switches the translevel number, $13BF, to different values in order to fool the message routine into displaying another level's message. After doing so, however, the original value is never restored; returning to the main level from a sublevel after hitting this block sends the player to a broken bonus game instead.
Some other points to keep in mind, none of which are rejection reasons but would be nice to see addressed:
This block uses header directive db $42, which does not utilize the WallFeet and WallBody labels, yet both of these labels are present as JMP Return.
I would like to see proper usage notes for this block included in the actual submission download, either as comments at the top of the .asm file or included as a separate readme. Many users aren't familiar with translevel number format, so claiming to display messages from "the level number equal to the block's map16 number" could easily confuse someone trying to display, say, level 105's messages. The description included in the print command doesn't even make note of the variable messages on X position.
For this code snippet here:
Code
LDA $9A
AND #$10
ROR
LSR #3
Why use ROR in this case? Carry is always clear when this code runs (which is good, because it would break otherwise), so this ROR is functionally identical to another LSR. It wastes neither space nor time, it's just… Curious, is all.
There's most certainly potential here, just needs a little care.
Tested with Asar 1.71, Lunar Magic 3.11, SA-1 1.32, Snes9x 1.59.2, GPS 1.4.1.
1 
Follow Us On