The VG Resource

Full Version: Any reason not to use checkerboard pattern bg?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
So I've started ripping my first sprite sheet, and my gut instinct was to use a checkerboard pattern for the background to keep the sprites aligned as they would be by the system (in multiples of 8 pixels) to make animating easier for anyone who would be using them, so they don't have to manually align anything. Then I browsed around a lot of games on here and noticed that I couldn't find a single sprite sheet that does that, and almost all of them are just thrown on a single solid color background. Is there a reason for this other than "it takes too much time"? I just want to make sure I'm making it easier for whoever is consuming these sprite sheets, but maybe this will make it more difficult, or there's something I'm not aware of. Big Grin

(Edit: I've also noticed there aren't many transparent PNGs and most people choose a background color instead. Is there also a reason for this standard?)
I leave the grid boxes for tiles (8x8) to make sure nothing is cut off when I add ithem to the sheet. The grid function of my graphics program really comes in handy for that.
Certain sfx like explosions, etc. get custom grid boxes because it's really useful for them having the correct alignment. I use a certain fix point for every frame and then cut the grid boxes until they're all only as big as the widest and tallest frame.
Example:
https://www.spriters-resource.com/snes/l...et/199068/
It's too much effort for everything else, though.

This is pretty much my own style on how I work with these games. In the end, different rippers put different amounts of effort into their sheet and this is why you see a lot of variety on this site.
Same goes for transparency, which I personally use for large level sheets (SNES) or if the extracted sheet already has it (PC, Mobile). So all in all, it's personal preference and as you said, a time issue.

If you're unsure and want feedback, you can open a thread here and get some comments on your stuff:
https://www.vg-resource.com/forum-122.html
It's not just the case of "too much to do" but rather the case of very few have considered at all and on the off chance that the checkboard uses one of the colours that the sprites use. The chances are extremely low but is possible. It can also be a visual reason. For people who have a visual impairment, the checkboard might be too distracting making them harder to see the sprites. Using a single colour makes it easier to see the sprites, transparency as well but more on that later.

Also this from experience ripping on Genesis, Master System and Game Boy games, sometimes the sprites don't align for 8x8. You might get a sprite where the first four tiles align, then the next four tiles it might shift one or two pixels towards the left or the right, then the next row might have the same as one or two but might be completely different too or even two tiles have to be aligned. That's not including sprites where you might have a sprite where the middle is 8x8 but then have to vertically align. A lot of it is due to space constraints in the ROM.

It sounds confusing so I'll give an example. This from the cancelled San Francisco Rush on the Game Boy, this is what the sprite looks like when you arrange the tiles and align them to look like how it appears in game:
[Image: sanfranciscorushgbc-car-example.png]

Then there are systems and computers that don't align to 8x8 at all. ZX Spectrum, Amstrad CPC and Commodore 64 (the 3 8-bit computers that I have been ripping from for the past few years) all have their standards that vary from game to game. A few do indeed fit towards 8x8 but usually just don't. Spectrum and Amstrad along with the Amiga and Atari ST use bitplanes so it goes 8 pixels horizontally, then 16 pixels horizontally and so on but the vertical can be unlimited. A sprite to use the loosest term can be 8x1 or even 8x192 (even 4x192+4x192 if shadow masks are done as a strip). So when it comes to aligning, that's an issue when it comes to animation e.g. Sprite 1 might be 16x31, Sprite 2 could be 24x28 while Sprite 3 possibly be 16x29. It's the case of trying to respect the sprite boundaries but doesn't always work out... C64 is 24x21 in terms of dimension for a sprite but different for the CharSet.

Relating to 8x8... When it comes to aligning and arranging sprites, the graphics program that I use does offer grids to make it easier. For space reasons, I tend to use 4x4 on my sheets but older ones were indeed 8x8. Enough so a person can get the sprite without the mistake of accidentally getting another but compact enough. Ripping from Amstrad is 8x8 since the graphics are doubled in size on the graphics viewer (easier for me due to visual impairment) but shrunk to 4x4 when finished and MAME depends on what size the tiles are listed in the tile viewer e.g. 8x8, 16x16, 32x32, etc.

Many rippers do things their own way, some have the sprites close together and some have some breathing space. Some have sprite boundaries, some don't or both depending on the ripper. Some fully describe while others just have the sprites. They use different tools to do the sheets; some use MSPaint, some use GIMP or Photoshop, some use Sprite Sheeter (usually for something like PC or DS games where a character sprite is either one piece rather than tiles or already arranged when exported), some use GraphicsGale and some use something entirely different for the sheets.

As for the lack of transparency, well... tSR has been going around for a long time, some of the oldest rips don't use PNGs and the early ones that did can be traced back when Firefox and later Chrome had supported PNGs due to Internet Explorer having issues with the format especially broken transparency. Until at least the mid/late 2000s, Internet Explorer was the most used web browser and took until 2011 before it could fully supported PNG but by then a lot of people moved on to alternatives. It was the case of better to be safe than sorry and just stuck. For modern rippers, probably the case of being influenced by the old rips having a background but rips on more modern consoles tend to have transparency e.g. Gamecube/Wii rips. Rarely I do include transparency but usually just the single colour background, been doing that since Day 1 way back in 2006. (On a personal note, usually only have a transparent sheet if I know it's a one and done rip that's not a title screen rip or something. Having a background makes it easier to do updates whether its missing/incorrect palettes, sprites need re-ripping or missing sprites that can happen otherwise would have to strip the transparency and rebuild. Not all the WIP sheets are .gal, some are PNG outright.)

Another reason is in its early days and still applies to an extent today, the main use for the sprites are sprite comics and avatars. Fan games did also exist but at the time, it was more of the Game Maker type. ROM hacks again also existed but they weren't like they are now. That is also why many rips on the site don't have the sprite boundaries because the thought didn't apply when ripping during the 2000s/much of the 2010s. It was and again in some ways still thinking visually rather than technically.
Thanks for the insight guys Smile I'll experiment with a few different methods and see what I like. Definitely finding that my checkerboard pattern with sprites directly touching each other is way too visually cluttered and hard to look at, so I think I've got my answer there.