The VG Resource

I've been working on a Castlevania game lately (sorry, my card game is on hold cuz the mechanics were getting complicated). While working on scripting the Axe Knights (by recording their movement and going through it frame by frame in AnimationShop), I noticed some discrepancies between the actual sprite in the game and the sprite in the enemies sprite sheet here on Spriters Resource. Now, that in itself isn't mind-boggling. When you rip from the ROM rather than doing screenshots, the pixels in the ROM are aligned for efficiency -- if one sprite is 15 pixels wide and the sprite adjacent is 1 pixel wide, merge them into a single sprite and then shift them in the game. Sometimes these are easy to spot in the sprite sheets (such as when a sprite is supposed to be pillowed but you have one or two pixels that aren't). However in the case of the Axe Knight, there were a couple quirks I noticed that you would never have guessed were in the game just by looking at the sprites.



In the picture above, the sprites at the top are from the game. The sprites on the bottom are from the sprite sheet. The set on the left differs in that the arm and head are pulled away from the back. This leaves a gap right in the middle of the sprite. I caught this when an Axe Knight passed over a torch and I could see the torch showing through there. The set on the right differs in that the back foot is pulled away from the rest of the legs, leaving a gap between the knee and the shin.

So are these mistakes in the programming or did the Castlevania designers actually plan that out with some mystical farseeing powers? I mean, I can understand shifting a set of pixels to align them properly, but shifting a set of pixels AWAY FROM the rest of the pixels just seems really odd if it's going to cause graphical problems.

my dibs are on that the ingame sprites just suffered from some small, glitched tiling. one should be aware that most of not all of the sprites on the NES are composed of tiles made up of 8x8 or 8x16 pixels who move along in a coordinated fashion.

in fact, if you divide the sprite in 8x16 blocks you'll notice that the displaced part fits perfectly.

It's more "emulators aren't perfect," than glitched tiling. I could be wrong but the best way to determine is to get screen shots of the PC version. Not the original one, but the one that also had Simon's Quest, Dracula's Curse, Contra, and Super C. If said discrepancies occurs there, then I'm wrong and Theou's assessment would be correct.

It does make me wonder if it occurs in the FDS and MSX versions too.

---

Just checked the MSX version and it doesn't use the same sprites.

I can't seem to connect the thread's title question to the actual matter in said thread.

this isn't a lot of 'creativity', but rather a miscalculation of the placement of the sprites. If you measure the gap's height, you'll notice it's 8 pixels tall, which is each tile's heightxwidth. Pixelart in games are often drawn with tiles, and arranged in gameplay on the go. This makes easier fot the hardware to form images, as it can recycle graphics and thus economize valious space in the cartridge (for example, in Super Mario World, Mario's head tile is recycled through the whole walking animation; this is because of the fact the head doesn't need to change when he walks).

The problem with that is this makes hard for the programmers to accurately calculate every tile's position and which tiles to appear; these mistakes appear in this example you posted. Other examples would include the weird line of weird characters/graphics on the side of the screen on some games (principally when the screen scrolls), trouble of the hardware to render so much tiles (Megaman games), and in irl gaming, graphical distortion when you accidentally bump the cartidge.

Now, if you talk about CREATIVITY in NES sprites, then I can say people needed to be extremely creative when coming into making a visually pleasant game with so few resources. Back in the day, there were no easy methods to draw pixelart, like Graphics Gale or even MS Paint. Actually drawing them required programming skills, and every sprite they inserted on the cartridge would have to be in use someway (or it would simply waste space in the cartridge).

Super Mario Bros, for example, needed a LOT of planning before actually having graphics drawn for it. Shigeru Miyamoto made a bunch of paper 'sprites' so he could see how the sprite would look like in the NES, and he'd insert said sprite if the drawing was good. Here's some of several sketches that the dev team whipped up (some, if not all, were made by Shigeru Miyamoto himself):




The same was done with the older game Donkey Kong:




So, creating each graphic, one by one, was indeed difficult, forcing spriters to 'sprite' in paper first, as it was the easiest way to test them.

Also, such restriction also resulted in witty problem solvings.



the castles in the start and the end of the game uses the same tiles, recycling a huge amount of data. You can also notice that the bushes and clouds are the same sprite, only colored diferently.

So, I can rightfully say that making sprites for the NES (or any old console) took a shitton of creativity, because it didn't only need creativity on the actual designs, but they also had to be creative to make it fit within the hardware context.

You can learn a lot more in this Iwata Asks, http://us.wii.com/iwata_asks/mario25th/vol5_page1.jsp . It is an interview with the original SMB's developers and what they did to make the game.

Ooh nice post. Thanks for the planning sheets. That was informative. The reason I prefer ripping NES and SNES games over some of the more modern systems is a lot of later games waste space to keep things simple for themselves because the carts or discs can hold so much more. It's fun to see how they organized carts back in the NES days for me.

I'm still undecided on the Axe Knight, though. It happens every time he throws his axe, not just once or twice, so I think that rules out the emulator glitch.

By "creativity" here I meant I was implying that maybe the disjointed leg in his crouching animation might have been a way to add "animation" without creating new tiles just for the effect. Because yes, they do actually line up properly in most cases (which is what I did anyway in my game, except for the ducking sprite, which I went ahead and kept the "glitched foot" in.

I don't think that the gap was intentional; it looks too weird to be proposital. If anything, the tile movement should be natural enough, and a whole leg and clothes being ripped apart when throwing/crouching certainly isn't natural.

But your idea about making smooth animation with tiles is well-executed in other games. Joy Mech Fight, for example, uses the 'tiles animated separately' technique to make a very smooth fighting game without overforcing the NES' hardware. Coding apparently takes less space than whole sprites drawn individually, so this helped the game to run steadily and support several characters.

Another famous example would be Konami's Goemon Impact on the SNES games. Goemon Impact's limbs (more noticeably the arms) are made up of several pieces and each has their own animation, giving the impression that Impact has a ton of sprites. Still, this has drawbacks, such as Impact's designs being made of floating balls (ball-limbs are much more easier to animate since spheres require no rotation; but the outcome won't look realistic at all).