3D animation with sound in 64 bytes of assembler(old.reddit.com)
old.reddit.com
3D animation with sound in 64 bytes of assembler
https://old.reddit.com/r/tinycode/comments/d4kdco/3d_animation_with_sound_in_64_bytes_of_assembler/
9 comments
Excellent.
The submitted file in2war64.com shows only the blue "background" when run from bare-metal booted DOS floppy on a Pentium D (x64 based on dual x86) with its associated Intel graphics hardware. No sound either.
Your file "war" is a nice binary, works natively as sector 0 of a floppy disk, with a traditional FDD plugged directly into the legacy FDD parallel connector.
On the same hardware.
Also works with USB floppy drive, even on a UEFI PC as long as the Legacy/CSM is enabled and Secure Boot is disabled.
To use a common USB Flash Drive (UFD) natively instead of a floppy, legacy BIOS can require a partition table to be also present on sector 0 of the removable UFD. This can be effectively added by partitioning (format not needed) after copying "war" to sector 0 of the UFD:
from Linux command line:
First copy "war" to sector 0 of the UFD, where X is the identifier of your unmounted UFD:
(sudo) dd if=/<path to>/war of=/dev/sdX bs=512 count=1
This overwrites any MBR and partitontable that may already be on sector 0 of the target X UFD; with the functional "war" replacing the MBR, and zeroes replacing the partition table.
Only sector 0 is replaced, all other sectors remain unchanged.
At this point sector 0 of the UFD is no different from sector 0 of the working floppy disk.
Then create a partition on the target X UFD using cfdisk:
(sudo) cfdisk /dev/sdX
make it primary, full size, bootable, type 0C
Only the final portion of sector 0 is altered (leaving the "war" binary intact at the beginning of sector 0), all other sectors remain unchanged.
Then the UFD boots natively just like the floppy.
Still for UEFI need Legacy/CSM to be enabled and Secure Boot disabled.
Still no sound.
The submitted file in2war64.com shows only the blue "background" when run from bare-metal booted DOS floppy on a Pentium D (x64 based on dual x86) with its associated Intel graphics hardware. No sound either.
Your file "war" is a nice binary, works natively as sector 0 of a floppy disk, with a traditional FDD plugged directly into the legacy FDD parallel connector.
On the same hardware.
Also works with USB floppy drive, even on a UEFI PC as long as the Legacy/CSM is enabled and Secure Boot is disabled.
To use a common USB Flash Drive (UFD) natively instead of a floppy, legacy BIOS can require a partition table to be also present on sector 0 of the removable UFD. This can be effectively added by partitioning (format not needed) after copying "war" to sector 0 of the UFD:
from Linux command line:
First copy "war" to sector 0 of the UFD, where X is the identifier of your unmounted UFD:
(sudo) dd if=/<path to>/war of=/dev/sdX bs=512 count=1
This overwrites any MBR and partitontable that may already be on sector 0 of the target X UFD; with the functional "war" replacing the MBR, and zeroes replacing the partition table.
Only sector 0 is replaced, all other sectors remain unchanged.
At this point sector 0 of the UFD is no different from sector 0 of the working floppy disk.
Then create a partition on the target X UFD using cfdisk:
(sudo) cfdisk /dev/sdX
make it primary, full size, bootable, type 0C
Only the final portion of sector 0 is altered (leaving the "war" binary intact at the beginning of sector 0), all other sectors remain unchanged.
Then the UFD boots natively just like the floppy.
Still for UEFI need Legacy/CSM to be enabled and Secure Boot disabled.
Still no sound.
Could you go one level further and get it working with https://bellard.org/jslinux/?
I was there at Function when it was shown on the big screen, we brought something for c64. At first I expected something else to show up, but then I remembered it was 64 bytes. Sixty four bytes! 256byte scene is insane. I've noticed recent 256b releases are high res. Not sure how they do it, definitely not 13h. Anyways, this 256b still takes the cake: https://youtu.be/eYNoaVERfR4
My cynicism about the widespread disregard for software bloat in the industry is tempered whenever I see stuff like this. Ask a javascript developer to do this and they'll end up with 1500 npm dependecies with an oddball collection of incompatible React plugins, 3d visualisation frameworks, and a codebase that'll be incompatible with the latest and greatest versions of all of these six months from now.
Yeah I know assembly language isn't a sensible choice for all but a tiny specialized niche of projects, hardware/bandwidth is far cheaper than developer time and so on but it's still refreshing to see people doing this kind of thing just out of pure passion.
Yeah I know assembly language isn't a sensible choice for all but a tiny specialized niche of projects, hardware/bandwidth is far cheaper than developer time and so on but it's still refreshing to see people doing this kind of thing just out of pure passion.
Went to rent a bike ("zagster") yesterday. required 242MB app. no space on phone and that's a good chunk of my monthly data.
A little OT but this is why I fell in love with Go (Golang) I think. There's something about the elegance of concise programs written in simple languages.
The 1500 npm dependencies problem you speak of is exactly what I expect to never even see, let alone have to deal with, in the Go ecosystem. It's not exactly surprising coming from one inventor of UNIX and C (Ken Thompson) and Rob Pike, two greats from Bell Labs, but when I heard that the creator of NodeJs had ditched that to go work in Go, now that I registered loud and clear.
After seeing for myself, I can understand. Go is a wonder, truly, and such a treat for systems (from sysadmin to CI/CD passing by performance, readability and safety). Something like Js can only eventually collapse on itself, when there's a better alternative. I mean, we could just as easily bundle a Python interpreter in browsers (to name just one candidate), Js is the frontend bible written in stone only because we keep it this way. Progressive apps are already showing a way between browsers and OS and I expect this line to get ever more blurry as virtualization (containers etc) continues its re-imaging of the entire computed infrastructure.
The 1500 npm dependencies problem you speak of is exactly what I expect to never even see, let alone have to deal with, in the Go ecosystem. It's not exactly surprising coming from one inventor of UNIX and C (Ken Thompson) and Rob Pike, two greats from Bell Labs, but when I heard that the creator of NodeJs had ditched that to go work in Go, now that I registered loud and clear.
After seeing for myself, I can understand. Go is a wonder, truly, and such a treat for systems (from sysadmin to CI/CD passing by performance, readability and safety). Something like Js can only eventually collapse on itself, when there's a better alternative. I mean, we could just as easily bundle a Python interpreter in browsers (to name just one candidate), Js is the frontend bible written in stone only because we keep it this way. Progressive apps are already showing a way between browsers and OS and I expect this line to get ever more blurry as virtualization (containers etc) continues its re-imaging of the entire computed infrastructure.
It's no coincidence that the three creators of Go have been around long enough to remember the simpler days.
Oh indeed. And how enriching it is to the programming and systems ecosystem at large.
I'm so thankful that computing evolved so fast that we can be here now, from there/then, and yet still have relatively young giants walking among us. The program-star hall of fame of very alive and active pioneers / creators is honestly humbling and inspiring.
I'm so thankful that computing evolved so fast that we can be here now, from there/then, and yet still have relatively young giants walking among us. The program-star hall of fame of very alive and active pioneers / creators is honestly humbling and inspiring.
I enjoy Go, but I'm still searching for a way to do a GUI. Qt? Would like to avoid a web browser UI.
Same here, GUI is a secondary concern in the Go ecosystem. But it only takes one big project, right...
Tbh, I don't know how or why the language wouldn't be suited to very elegant front-end design, I feel the biggest obstacle is general framework fatigue: people are tired of seeing every language under the sun try to do everything, so they stick with what's existing on the frontend (convergence around a few Js frameworks over the last years for instance), while Go devs keep it to server/infra mostly (unrelatingly, just doing their thing). These being just two examples.
Thus GUI options are the same as anything else afaik, provided you can interface with your Go backend. Note that I've heard bad experiences with code injection so I wouldn't try that first nor without extra care.
The solution depends on your use-case, and what platforms you are targetting. I'm partial to KDE on Linux desktop thus Qt is a strong candidate for me; however I dislike non-native apps in most situations so I'm not sure I'd recommend Qt for a wider project in target OS scope. Again, use-case, design specs should preside over this debate. Embedded, sure.
Tbh, I don't know how or why the language wouldn't be suited to very elegant front-end design, I feel the biggest obstacle is general framework fatigue: people are tired of seeing every language under the sun try to do everything, so they stick with what's existing on the frontend (convergence around a few Js frameworks over the last years for instance), while Go devs keep it to server/infra mostly (unrelatingly, just doing their thing). These being just two examples.
Thus GUI options are the same as anything else afaik, provided you can interface with your Go backend. Note that I've heard bad experiences with code injection so I wouldn't try that first nor without extra care.
The solution depends on your use-case, and what platforms you are targetting. I'm partial to KDE on Linux desktop thus Qt is a strong candidate for me; however I dislike non-native apps in most situations so I'm not sure I'd recommend Qt for a wider project in target OS scope. Again, use-case, design specs should preside over this debate. Embedded, sure.
https://js1k.com/
Language is hardly ever the cause of any significant bloat.
Language is hardly ever the cause of any significant bloat.
Thanks for reminding me about js1k.
It's a fair point. But common practice emerges in communities, and the npm JavaScript package proliferation is real.
I can find similar dependency hell problems in every platform I have used.
Maybe it's me. I could charge a fee to stay away from your favorite platform...
It's a fair point. But common practice emerges in communities, and the npm JavaScript package proliferation is real.
I can find similar dependency hell problems in every platform I have used.
Maybe it's me. I could charge a fee to stay away from your favorite platform...
Take a look at this old classic 256b legend: https://news.ycombinator.com/item?id=20115022
3D, Raytracing, fish-eye effect, movement.. its fascinating!
3D, Raytracing, fish-eye effect, movement.. its fascinating!
This demo on YouTube: https://www.youtube.com/watch?v=CAAuIgjrZWY
The 1080p MP4 at that link is 32.5MiB.
In-browser emulation:
https://parkertomatoes.github.io/v86/?type=com&content=FBO6M...
I got this:
> The string contains invalid characters.
> The string contains invalid characters.
Thanks for reporting! What's your browser? I've only tested with a recent Firefox and Chrome on Windows. I know iOS doesn't work but I don't have a means to debug it.
Otter Browser provides an up-to-date Webkit (i.e. not Blink/Chromium) engine on Windows, that replicated a lot of Safari-only bugs for me in the past.
Thanks for the recommendation!
I’m using Safari on iOS 13.2. I can help debug I’d you’d like, but I’m no expert ;)
Same here with Safari 12.1.2 on MacOS 10.14.6, just FYI.
Same here, iOS 12.4.1 Safari
Works for me on Firefox 60.9.0esr. No sound though.
One sad part of the obsolescence of "classical" BIOS is the loss of access to basic functionality like simple graphics modes.
Of course it's one downside among many upsides but I think there's a point to having a simpler interface to allow stuff like this
With 64 bytes you can't even initialize a window on Linux or Windows.
Of course it's one downside among many upsides but I think there's a point to having a simpler interface to allow stuff like this
With 64 bytes you can't even initialize a window on Linux or Windows.
This is where small embedded devices come handy. Any small cheap board with video output can be turned into a powerful demo (and games) playing machine, at 1/50 or less the cost of hardware in the demoscene era.
As a programmer the demoscene has always fascinated me, but I don't know if I can handle that rabbit hole.
A go binary to do the same thing would be at least 50MB. ;-)
You can write plan 9 assembly straight into go. I'm not sure if it would work, and it sort of defeats the purposes of go, but it wouldn't be 50mb.
Here's another 64-byte demo by the same hacker.
https://www.pouet.net/prod.php?which=78044
I saw it discussed on Lobsters.
https://lobste.rs/s/lpnlyd/tiny_64_bytes_ms_dos_ray_tracer
https://www.pouet.net/prod.php?which=78044
I saw it discussed on Lobsters.
https://lobste.rs/s/lpnlyd/tiny_64_bytes_ms_dos_ray_tracer
demoscene ftw!
Modified source is here: http://oirase.annexia.org/war.S