"it's obvious that you cannot produce anything nearly as compact and efficient with a compiler."
It's not obvious. We can argue over what's "nearly", but without even trying, manually converting the assembly to C I get 71 (1.5x) instructions out of gcc and that includes an inlining of animatebird. The resulting code is otherwise not so far from the original. It certainly reads more poorly, but that's to human eyes not x86. I'm not sure which would be more performant, and playing more carefully with the code and optimizations it can probably get even better.
Well, on Android the original Flappy Bird was 894kb in size,
and this Floppy Bird is only 8.7kb.
Plus the 8.7kb includes enough utility code to obviate the need to load an OS for the game to run on top of, so the size ratio actually is better than the apparent 100:1.
"Well, on Android the original Flappy Bird was 894kb in size, and this Floppy Bird is only 8.7kb."
You're actually making my point. Virtually the entirety of both those numbers is going to be image (and, on the Android version, audio data). Using lower-resolution assets is not something reserved to assembly language, and the size of the code is just not an issue next to that, most of the time. The biggest exceptions on desktops/servers being when executable makes the difference between spilling instruction cache and not. Things can get tighter on embedded, but there too tables and stuff are more often the cause of contention.
"Plus the 8.7kb includes enough utility code to obviate the need to load an OS for the game to run on top of, so the size ratio actually is better than the apparent 100:1."
Enough code to obviate the need for an OS (for this narrow use case, in Real Mode with BIOS calls available) is probably fewer bytes than enough metadata to convince Android to run you. But as mentioned, you're not actually comparing code size at all really.
"The TAB key changes the bird's color scheme."
I'm not sure what your point is here. Cycling palettes is a neat trick, but nothing new, nothing complicated, and certainly nothing that couldn't have been done as easily in another language.
Edited to add: Perusing your other comments, you seem to have plenty more savvy than your comment would show... were you trolling or trying to make some oblique point that I missed or what?
Well, this is a time I didn't really have an opinion
except maybe I like for things to take up less space for
the same functionality. I was just putting up the
numbers that I observed.
I didn't realize the Android version might have been
more sizable due to graphics & audio, so I guess
the functional code difference might not be as dramatic
as the 100:1 download size ratio after all.
The Tab key function was just another observation that
I had not seen in the documentation, don't even know
if it is intentional.
Check my other comment on this topic, it would be good
to get some feedback from the author.
It's not obvious. We can argue over what's "nearly", but without even trying, manually converting the assembly to C I get 71 (1.5x) instructions out of gcc and that includes an inlining of animatebird. The resulting code is otherwise not so far from the original. It certainly reads more poorly, but that's to human eyes not x86. I'm not sure which would be more performant, and playing more carefully with the code and optimizations it can probably get even better.