In any case, the point is that images and their palettes live in different places, and they get to the system in different ways. That's (part of) why you'll notice that many enemies show up in lots of levels, while others only show up in a few. So many sprites will be unaffected by level-specific palettes. Indeed, even in SMW, there are some palette entries that simply don't change from level to level, and many sprites use colors from them. But individual games can do things a different way. And if the level loads the right palette for the sprites that level uses, then everything appears fine. That is, each level has a setting for which palettes to use (a palette of palettes). How does that happen? Exactly and only because that level just so happens to put those colors there. But the images those sprites use depend on certain colors being in certain palette indices. A sprite is a game construct that is attached to a level. The link between the two is merely a well-educated coincidence. Palettes tend to be hard-coded or otherwise live in tables in entirely different places in the ROM. Images tend to live in large blocks of data in the ROM. The source of the palette was not imaging software it was designed explicitly by the developers.įor the SNES, image data and palette data live in different places. Those tools are given a palette to work with, and you build your image only from those colors. Look around the Super Mario World rom-hacking scene for examples of the kinds of art tools they would use to generate sprites. The tools they used to create those images were not programs like Photoshop. Once all that was nailed down, they just did their work, making each sprite work with the palette colors they worked out Again, this probably involved many iterations. They probably got together with the game designers so that they could have sprites that conflict in their palette, simply by forcing the developers not to put conflicting sprites in the same level. They probably went through several iterations of palettes, so that they could get the most out of the limited color palette space. This ain't rocket science.Īt some point in time, the artists got together and came up with the available color palette. Which means that a palette has to serve the needs of multiple sprites. You have different palette indices for variety of sprites, but a lot of sprites are going to have to share. Multiple sprites will use the same palette index. No SNES game developer would be so wasteful as to assign each sprite its own individual 8-color palette index (except maybe for the main character). If you have a bunch of different sprites, then they need to be designed to share a lot of colors. You set the palette at the beginning of the frame and then render everything in the frame with it. You don't get to change palettes in the middle of rendering a frame on the SNES. Well, it's a complex interplay between the two, but the needs of the palette primarily inform the art design of an image. You don't design your palette for your images, you design your images for your palettes. In SNES-style hardware, palettes are global. That is, you're thinking of palettes as a part of the image, with each image owning its own palette. All with the same result.Ĭurrently, i am drawing sprite zero at #$d0 if it helps (and it is definitely colliding with background).You're thinking of paletting from a modern perspective. I tried different versions of the sprite zero check discussed here. But with the sprite 0 hit and trying to separate the screen, the color does not change, I get *animated junk* at the top, scroll value was pshed off, and it seems that in some spots it is drawing the right value (f5, which should be a blank tile) but from the wrong pattern table. If I skip the sprite 0 loop and just do the single color swap, no problem. so something with the sprite zero check is the problem? this works with no issue if I don't do the sprite zero check should change a color in the last sub palette. some arbitrary numbers in a dummy loop here to try to get to the end of the scanline checks game state.if not a screen where sprite 0 is drawn, skip this code
0 Comments
Leave a Reply. |