Just taking some time cleaning up the main sprite sheet and made a new move for the player character. Now it can crawl though tight spaces. Falling flat on the ground may also be good for avoiding dangers, but you’re less agile while crawling. Another change is that while the player throws bombs in an arc while standing, ze is planned to roll them on the ground while ducking.
While i’m at it. Here’s a look at how sprites are organized when running. NES sprites are 8×8 pixels (unless the PPU – picture processing unit is in 8×16 mode, which is sometimes useful but not always). So mostly, you have to piece several sprites together to make a decently large and detailed character. For example, little mario is 2 by 2 sprites, side by side, and big mario is 2 by 4. But there’s no rule that states that sprites must be side by side. You’re entitled to free placement if your own code permits it.
I’m exploiting this fact to two effects:
- make the running animation smoother than most NES era games
- sometimes have the character be fewer sprites in total.
The second point is sort of important because on the NES you have a sprite bandwidth of 8 sprites per scanline (that’s a horizontal line on the screen). If there are more than 8 sprites, the 9th and so on won’t show. Programmers quickly figured out that they could hack their way around the limitation by rotating the priority of sprites. That’s why you see flicker in a lot of NES games – which is still better than sprites being invisible.
Slimming the need for sprites on the same scanline means less flicker – and there will be flicker, because the player controls both a vehicle and a character, and then there’s projectiles, other actors, and so on. A side by side/mario style animation would in this case be a constant 2×3=6 sprites at any one cel, but instead in oscillating between using 5 and 3.
Tilespace-wise, it’s not very effective – the running alone is using 30 tiles if i remember correctly, though some of it can be reused for other actions. You can have 256 sprite tiles loaded in at the same time and that space has to be shared by enemies, items, HUD components and so on. Given that we’re using one quite agile player character and two vehicles ze can ride, that takes up some space. Luckily we can swap strips of it between rooms and areas so we can load in different enemies and items according to need, since the cartridge is using CHR RAM instead of ROM.
The animation is slightly dated. Nathan, the programmer, found that the engine would be more effective if all objects were anchored from the bottom left corner, and this animation has it’s origin at the center-bottom. That’s a quick fix for me, though.