We've managed to restore 99% of our file loss earlier in the year, but it's now THE FINAL COUNTDOWN. Visit the wiki file request topic to help make Sonic Retro better than ever.
SCHG:Sonic 3 & Knuckles/Art Editing
From Sonic Retro
| SCHG: Sonic 3 & Knuckles |
|---|
| Main Article |
| Art Editing |
| Editing Art |
| Object Editing |
| Editing Objects |
| Level Editing |
| Editing Levels |
| Music Editing |
| Editing Music |
| RAM Editing |
| Editing RAM |
There are several different tools that can be used to edit art. SonED2 is probably the best tool to use for editing level art, and can also be used on palettes. HivePal is also a great tool for editing palettes. SonMapEd is useful for editing both art and mappings - it can extract data from either a ROM or use split binary files, and has internal compression/decompression support.
Uncompressed Art Locations
Nemesis Compressed Art Locations
Zone Independent
| Offset | Description | # of blocks |
|---|---|---|
| $AD430 | Unknown Black Circle | 16 |
Special Stage
| Offset | Description | # of blocks |
|---|---|---|
| $AD7BC | Special Stage HUD | 18 |
Kosinski Compressed Art Locations
Palette Editing
Usually, it's not really necessary to edit a palette in hex. Palette editors give you instant feedback for each RGB value, and the palette can be easily saved as a separate binary and reimported into the ROM. However, it is sometimes desirable or necessary to do it in hex, and it can't hurt to know how it's done.
For palette locations, see SCHG:Sonic 3 & Knuckles/Art Editing/Palette Locations. For information about the palette format, see Megadrive palette.
Pattern Load Requests
PLRs tell the game engine where to get Nemesis-compressed art data and where to put it. The format is rather simple: each PLR starts off with a one-word header, which is the number of entries to load - 1. The actual entries follow this header - each entry is one longword, which is the location in ROM of the compressed art, followed by one word, which is the location in VRAM to decompress to.
The RAM queue is $60 bytes long, meaning it has space for 16 PLRs. However, a coding error in the clearing routine means that storing a PLR in the last slot screws everything up, so effectively only 15 requests can be stored at one time. Note that the routines that load PLRs into the queue do not do any bounds checking, and it is quite easy to create a buffer overrun condition. Further, both lists seem to be moved into the queue at the same time, so even if neither one is longer than 15 requests, they can still overrun the queue and destroy the variables that are stored just beyond it. Make sure that the primary and secondary PLR lists are no more than 15 requests long.
