The value they chose for the shadow scaling, 65, was almost certainly picked to create this effect. It reduces the sprites to a quarter of the size. 64 would be a more obvious and correct value and would not have created this shimmering effect.

If the counter doesn't increment by some multiple of 256 over the entire frame, then each frame will start with a different counter value and you'll get slightly different rows selected on scaled sprites. Games tend to pick scaling values that avoid this, PuLiRuLa exploits it!

Each sprite starts with whatever the counter value is at the end of the previous sprite and each FRAME starts with whatever the previous frame ended with. It just never resets and I can't find any mechanism that causes it to reset.

I had assumed that these counters get reset for each new sprite. In the previous example the 8 rows of the 16 row sprite that get draw will be different if the counter starts at a number >= 128, because the counter will overflow at different times. But it NEVER resets.

Unscaled sprites increment by 256 every time, so it overflows for each input row and every row gets draw. If you want to half the size of a sprite you set the increment to 128, then it only overflows every second row and half the rows get drawn.

Each 16x16 sprite on the F2 can be scaled all the way down to 1x1. For vertical scaling this is down with an 8-bit counter. Each sprite specifies a zoom value and for each of the 16 rows the counter gets incremented by that value. When the counter overflows it draws a row.

When I saw video from an arcade PCB I guessed that the shimmer was something do with what I called "spooky" sprites which is something I encountered when I made some tests for sprite positioning and scaling. I ignored it at the time because I hadn't seen any games use it.

My home town has a wind farm and I think they are awesome. There is even a bunch of hiking trails through them and you can get right up the the turbines. Lots of locals are opposed to them though, not sure what their reasons are.

NeoGeo is a 27c1024 which is a 1MBit, 16-bit ROM. RP2350B would have enough pins to do it. There have been times when I wish I support ROMs like that, but I haven't been motivated enough to design the board.

It's a Kojima game, so I'm assuming that the less you know, the less confusing it will be.

Amazing project and amazing work. Congrats!

Ibuprofen, ice, Diclofenac sodium cream.

The end result was pretty easy to replicate in the core. Of course I haven't found a single game that actually uses this functionality. Maybe something will come up, but even if it doesn't it's nice to uncover more secrets.

With that I could analyze the results and work out what each flag does. The hardest part was finding the right variety of colors and shapes to make the different interactions obvious. I thought simple shapes and primary colors with be most useful, but they ended up hiding a lot of stuff.