I like his girlfriend implementation better: https://github.com/icebreaker/girlfriend
Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
61–70 of 73 posts
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#62Earlier quoted context omitted.
ticks() and sleep() also use BIOS. The author could have implemented this by handling IRQ 0. :-) Come to think of it handling the keyboard interrupts isn't that hard either... Also looks like boot.asm uses the BIOS to read the rest of the program...
Seems like if the "boot.asm" (actually sector 0 of the floppy) could be made relocatable away from sector0, then it could still be functional when stored in a filesystem (including on a HDD) not unlike BOOTSECT.DOS. The remainder of the floppy (sectors 1 through 16 proper) when copied to the same sectors (which are normally blank and unused) on a MBR/BIOS style HDD work just the same as from floppy without having to…
This stuff is kind of annoying to write. When I wrote stuff on raw metal (hobby OS kernel) I mainly just built an ELF file that GRUB can load. (Surprisingly easy to do.) Or, in days before that when I used more Microsoft stuff, a small .COM file where ms-dos or freedos is a glorified bootloader. (DOS is totally cool with a program hijacking everything.)
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#63Earlier quoted context omitted.
"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 no…
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. The TAB key changes the bird's color scheme.
Good to get your message.
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.
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#64Is "I made a Flappy Bird/2048 clone with a TWIST" the 2014 equivalent of "I installed Linux on my hat"?
Although I admit this is more impressive than the usual "Floppy Bird only slightly different."
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#65Thanks for wasting 4 minutes of my life! For some reason, I picked up a Wyse Winterminal S50 from Weird Stuff last week... a thin linux client box from 2006 that has some sort of underpowered x86 and very little memory. So I was playing with it and it has this weird linux on it that lets you set it up to very slowly browse the web and such, but it wasn't very interesting, all told. When I saw this project come up, I…
Turns out after you have written the floppy IMG to a blank
uFD or HDD, and it boots and plays the game, then you can
partition the drive (I used Linux Mint), format it as
FAT32 or NTFS, and use the full drive for mass storage
without a conflict.
Same drive still boots to Floppy Bird only, unless you install some other OS or something which overwrites the Floppy Bird bootloader on sector 0, and give up the bird.
Partitioning and formatting alone do not overwrite the MBR, even if it is just a custom floppy boot sector at the time.
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#66This is just beautiful: https://github.com/icebreaker/floppybird/blob/master/src/mai... Nicely structured code! I'm almost tempted to port it to amd64, just for fun. After all we really don't need any more x86/16bit example code, we need more amd64 code! :-)
I've been saying this to my co-workers over the past week as I've gotten into modern day assembly (ARM, but still): It's basically a high level language at this point! It's amazing how much structure you can actually give yourself with modern tools.
> It's amazing how much structure you can actually give yourself with modern tools.
Like a compiler? >:)
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#67I'm wondering: how hard would it be to add sound to this thing? I think it uses Piezo sound, which is probably easily addressed. But what about midi or PCM output? Would you have to target every manufacturer specifically?
I really liked how fast my computer "booted" into the game. I would totally start collecting games like these if there were a scene.
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#68Earlier quoted context omitted.
Assembly is about as nonportable as you can get. Hardware access (not exposed by other languages), speed, and possibly executable size are the practical reasons one would write in assembly. The second and third are almost entirely outdated - storage of executables is free relative to storage of data; hardware speeds have made "slow" programs plenty fast for most things; and compilers can do better than you can quickl…
> Hardware access (not exposed by other languages), speed, and possibly executable size are the practical reasons one would write in assembly. This is a bit misleading, accesses to physical memory, disks and to other devices are usually protected by the operating system, not by the language. So you don't have direct hardware access because you program in assembly, but because you run a program without the control of…
>The only thing that you can do with assembly and that you can't really do with higher level language like C is accessing processor specific registers/instruction sets (e.g. SSE). And this is typically done using inline assembly snippets, as there is no reason to write a whole program in assembly when you only need to optimize a single function.
The other three most important things you can do in assembly that you can't do in C are:
* Indirect jumps (aka the "labels as values" or "computed goto" extensions admitted available in GNU C)
* Directly accessing status flags like the carry flag (necessary for efficiently implementing bignum arithmetic and CPU emulators)
* and optimizing register allocation across complicated control flow (like language interpreters or emulators)
It can absolutely be worthwhile to write an appreciable portion of a program in assembly if these "features" make the code significantly faster or even easier to express.
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#69Is "I made a Flappy Bird/2048 clone with a TWIST" the 2014 equivalent of "I installed Linux on my hat"? Although I admit this is more impressive than the usual "Floppy Bird only slightly different."
And all of that, in 24 lines of javascript.
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#70I'm wondering: how hard would it be to add sound to this thing? I think it uses Piezo sound, which is probably easily addressed. But what about midi or PCM output? Would you have to target every manufacturer specifically? I really liked how fast my computer "booted" into the game. I would totally start collecting games like these if there were a scene.
Correct me if I'm wrong, but I think you could cover fairly wide range of hardware with two generic drivers, AC'97 and HDA.
edit: for this project specifically there is the small problem that you probably need to enter protected mode for "modern" audio.