RCT1 Sprite Transparency & Unpack Issues: A Deep Dive

Hey everyone, let's dive into some interesting issues I've been running into while trying to unpack sprites from the original RollerCoaster Tycoon (RCT1). I figured it'd be a good idea to share my findings, especially since most tools out there seem to be tailored for RCT2. We're going to get a bit technical, but I'll try to keep it as easy to follow as possible. We'll be focusing on the challenges I've encountered with inner-transparency and some pesky problems related to the first and last scanlines during the unpacking process. Let's get started!

The Inner-Transparency Bug: A Sprite's Worst Nightmare

One of the biggest hurdles I've faced is how RCT1 handles transparency within its sprite files. It seems there's a bug that throws a wrench into the whole process. Specifically, the unpacking process doesn't always handle transparency correctly, which can lead to some seriously messed-up sprites. Now, the way these sprites are typically compressed is that transparency is expected at the beginning and end of the main sprite body. Basically, it assumes that the transparent pixels are neatly tucked away on the edges. However, the game, and the unpacking tools, don't always account for transparency interspersed within the scanlines. This means you might have a transparent pixel in the middle of a row of colored pixels. This is where things start to go wrong. When this happens, it throws off the header count, which tells the unpacking tool how many pixels to read per row, and causes the rest of the sprite to become completely scrambled. It's like trying to put together a puzzle with some missing or misplaced pieces.

To give you some examples, I've noticed this issue cropping up with a number of sprites. Specific address ranges like 10335258 / 0x9db41a through 10342271 / 0x9dcf7f showcase this problem quite well. If you look at those sprites, you'll likely see the messed-up transparency issues I'm talking about. And it's not just the objects you build, It's also most of the scenery items, such as the trees and fountains. Basically, anything that relies on transparency within its image.

It's a frustrating issue because it means the sprites don't display correctly. You might get jagged edges, missing parts of the image, or just a general mess. The issue highlights a specific problem with how the older game handles its image compression. It's expecting a certain format of image data, which doesn't perfectly match the variety of ways transparency can be used within a sprite. So, when the unpacking tool encounters a different format, it misinterprets the information, leading to those visual artifacts. The implications of this issue extend beyond simple visual problems. It can affect the way the game renders objects, causing flickering, incorrect layering, or even causing the game to crash, depending on how the incorrect sprite data is being used. And because the problem is related to the specific format of the sprite files, the solution isn't as simple as tweaking a few settings. We must dive into the core of how the unpacking process works to figure out how to solve it.

Diagnosing the Root Cause of Transparency Issues

To truly understand and fix this issue, we need to dive into the technical details of how these sprites are compressed and unpacked. It's all about how the game stores and reads image data. The problem arises because the unpacking process anticipates transparency in a particular pattern. When it finds transparency in other places, it gets confused. Here's a breakdown of what's happening under the hood:

1. Compression Method: RCT1 uses a form of run-length encoding (RLE) for its sprites. It means that repeating sequences of pixels are stored more efficiently, along with information about how many times that pixel repeats. This is a common method for image compression.
2. Transparency Encoding: Transparency is usually handled by special color codes, meaning a specific color value is designated as 'transparent'. This value tells the game not to draw that pixel.
3. The Bug: The unpacking tool reads the compressed data and reconstructs the image based on its RLE and transparency rules. However, when transparency is not consistently located on the edges, the process goes awry.

The game expects the beginning and end of the image lines to have transparent pixels, but when transparency appears within a scanline, it messes up the expected pixel counts. The tools then misinterpret the data, which leads to visual corruption. Solving this problem requires more than a simple fix; we will need to change how the game handles the data. So it becomes necessary to adjust the unpacking process to correctly interpret the sprite data, accounting for transparency wherever it appears. This includes modifying the header count calculation and adjusting the decompression algorithm to handle transparency in different positions.

The Missing Scanline Mystery: A Case of Premature Termination

Now, let's look at another problem I've run into. It's also related to the unpacking process, but this time, it's about the first and last scanlines of the image. While the tools I've been using get the image dimensions right, it consistently seems to miss reading the last scanline. The end result is that the rest of the image is prematurely filled with 00s. It's a bit subtle, but definitely noticeable. If you change the Transparent_Element color to something like 00 255 00 (green), you can see that the last line is being filled by a separate function. It's like the unpacking process stops before it reads all the data for the last row of pixels.

And it's not just the last scanline; sometimes, it seems to miss the first row too, which leaves two rows of black at the end. Comparing the assets between RCT1 and RCT2, the difference is evident. The map icon at 10346766 / 0x9de10e is a good example of this phenomenon.

Deeper Understanding of the Missing Scanline Problem

The issue with the missing scanlines is due to an error in the unpacking algorithm. The code that's supposed to read and interpret the sprite data is missing, resulting in only some of the image's information being read before the process is finished. To understand this in more depth, we'll need to examine how the image data is organized within the sprite files and pinpoint the exact part of the code causing this problem.

1. Sprite Data Organization: RCT1 stores sprite data line by line, meaning each row of pixels in the image is stored sequentially. The unpacking tool reads each line, processes it, and then moves on to the next. The tools depend on the header information that tells them how many pixels to expect in each line.
2. The Error: It looks like the unpacking tool is failing to completely read the last line of image data. Either there's a problem with the loop that reads the lines, or it could be a misunderstanding of how the file format is organized.

When we compare RCT1 and RCT2 assets, we can find some clues. The map icon at 10346766 / 0x9de10e shows that it is missing from RCT1, as is the first line of an image. This suggests that the problem is not isolated to the last line, so it can impact any scanline. If the game is unable to read the last line, then the final result could be corrupted. The visual effect of this depends on the sprite. But in general, you might see parts of the image missing or incorrect.

The Role of Initial Conditions

It's worth mentioning that I'm using the csg1 from the absolute vanilla game with no expansion packs. It could be that the specific version of the game I'm using is causing the issue. I need to test different versions or game files to determine whether this affects the results. This way, we will understand how game versions or any mods could be causing this problem.

Potential Solutions and Future Steps

So, what can we do to tackle these issues? Here's what I think we should focus on:

1. Debugging the Unpacking Tool: The most important thing is to delve deep into the code of the unpacking tool. We need to step through it line by line to understand exactly how it handles transparency and how it reads the scanlines. This will help us pinpoint the exact source of the errors.
2. Adjusting the Transparency Handling: We might have to modify the code to account for transparency within scanlines. This means adjusting how the header count is calculated and making sure the decompression algorithm correctly interprets transparent pixels. You might need to add conditions that can recognize transparency and adjust the reading of the data.
3. Correcting Scanline Reading: For the missing scanline issues, we'll need to focus on the loops that read the image data. We must make sure that they correctly process the first and last lines of the images, as well as the intermediate lines. This will mean carefully examining the data structures used by the game.
4. Testing and Refinement: Once we have solutions, extensive testing will be crucial. We will test against a variety of sprites to ensure that our fixes work consistently. This is going to involve checking how the code behaves and how the games displays the images.
5. Community Collaboration: Let's get together and share our findings and solutions. Sharing our knowledge will speed up the process of solving these issues. If anyone has experience with RCT1 sprite formats, please chime in! The more the better.

These problems with transparency and scanlines have opened a window into the inner workings of RCT1. By understanding these issues and working towards solutions, we can create tools that offer players a deeper understanding of the game and let us get into the more advanced customization options.

Thanks for reading, and I hope this helped you better understand the inner workings of RCT1 sprites. Let's work together to unlock the full potential of these classic games!**