This simple game has gotten so much attention since it was released (and ten taken down).
Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
41–50 of 73 posts
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#42This is really cool. Is there a practical reason why you would write a game in assembly (speed? portability?)
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…
[deleted]
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#43This is really cool. Is there a practical reason why you would write a game in assembly (speed? portability?)
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 an operating system. This can be done in assembly, but also in C or in any other language that can generate native code.
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.
So I would say that having better hardware access is not a good reason to write an entire program in assembly.
On the other hand, building small, standalone executable file that use very little (stack) memory is still relevant for programs that run on very small (usually embedded) hardware. Especially when they need to run fast or to have low energy consumption. So speed and memory usage are still pretty good reasons to use assembly :)
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#44Earlier 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…
Hmm, I guess there is some room for misinterpretation.
First, you seem to think I was answering a slightly different question - "In what circumstances should I make the decision to write assembly?" The question I was answering was closer to "When people need to write assembly, why?"
The actual question, of course, was not quite either of those.
Also, addressing a point of ambiguity:
I did not mean "hardware access ([this is something that is] not exposed by other languages)" - that is, in general, wrong.
I meant "hardware access ([when the particular thing is] not exposed by other languages)". This includes SSE (though that is starting to be included as builtins in some compilers). Outside of SSE, I grant that there isn't much on x86 platforms that is relevant to a game, since games on x86 platforms typically run under an OS. It can be relevant if you're writing a driver, though. And this can vary substantially by platform.
And no, it's not a good reason to write an entire program in assembly unless a sufficient percentage of your program is calls to these things that the C inlines are just adding cruft.
"On the other hand, building small, standalone executable file that use very little (stack) memory is still relevant for programs that run on very small (usually embedded) hardware. Especially when they need to run fast or to have low energy consumption. So speed and memory usage are still pretty good reasons to use assembly :)"
No, that is substantially more misleading. Like I said, you cannot quickly do better than a modern compiler, and a compiler does it very, very quick.
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#45Super sweet! Does it have a switch that lets the computer cheat? http://www.catb.org/jargon/html/story-of-mel.html
I had not read that before.. a great read. thank you.
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#46Nice work, thanks for posting.
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#47For systems running Debian you might need to install a mkisofs replacement.
$apt-get install genisoimage $ln -s /usr/bin/genisoimage /usr/bin/mkisofs
builds fine after this.
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#48Earlier quoted context omitted.
It's also not really running on "RAW METAL" because it's using BIOS interrupt routines for drawing and input. It's still awesome, though, and the code is really cleanly written and easy to follow. Because the code is so nice, this would be a fun project to try to port to Protected Mode with its own HAL and maybe drivers for one set of hardware (perhaps QEMU's). Could be a fun experiment in why OSes are hard and x86 i…
vga.asm copies bytes directly to video memory in a raw manner, once it's in VGA mode. It only uses BIOS to switch into VGA mode ("mov ax, 0x13" and then "int 10h"), and back to text mode before rebooting when you quit. It does use BIOS to read the keyboard. It also reads bytes from sectors of the disk using BIOS rather than the OS when it starts up. The sound is a beep created with raw "OUT" commands on the data port…
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...
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#49Earlier quoted context omitted.
> 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…
Hmm, I guess there is some room for misinterpretation. First, you seem to think I was answering a slightly different question - "In what circumstances should I make the decision to write assembly?" The question I was answering was closer to "When people need to write assembly, why?" The actual question, of course, was not quite either of those. Also, addressing a point of ambiguity: I did not mean "hardware access ([…
> I meant "hardware access ([when the particular thing is] not exposed by other languages ...
Ok, I agree.
>Like I said, you cannot quickly do better than a modern compiler, and a compiler does it very, very quick.
I'm not sure what you mean by "quickly" but this submission proves that it can be done in reasonable time. And if you look at the code (for example here: https://github.com/icebreaker/floppybird/blob/master/src/gam...), it's obvious that you cannot produce anything nearly as compact and efficient with a compiler.
So, claiming that assembly is still a language of choice nowadays was maybe exaggerated, nevertheless it's nice to remember that no matter how good they are, compilers come with a cost. If you need some evidence simply compare the submitted code with any code produced with a compiler.
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#50Earlier quoted context omitted.
Hmm, I guess there is some room for misinterpretation. First, you seem to think I was answering a slightly different question - "In what circumstances should I make the decision to write assembly?" The question I was answering was closer to "When people need to write assembly, why?" The actual question, of course, was not quite either of those. Also, addressing a point of ambiguity: I did not mean "hardware access ([…
> I meant "hardware access ([when the particular thing is] not exposed by other languages ... Ok, I agree. > Like I said, you cannot quickly do better than a modern compiler, and a compiler does it very, very quick. I'm not sure what you mean by "quickly" but this submission proves that it can be done in reasonable time. And if you look at the code (for example here: https://github.com/icebreaker/floppybird/blob/mast…
"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.