you might already know, but this is because the game has a small executable but basically spends minutes at startup generating all the possible textures the game will need procedurally.
I do find it funny how they were nice enough to compress this executable, with the uncompressed version coming at a whopping 108kb. Meanwhile, the screenshots are each about 2MB
Sure.
All you have to do is write all the programs you need. You get an editor and a web browser to get you started!
I used to copy Apple II games, and they ran in 48k and often shared a floppy. Some even did vector graphics, which was kind of like deep black magic back then. The Amiga (which could actually do graphics properly) people will tell you similar stories.
That AI ought to be stuck on a floppy for a few years to teach it some manners.
Minimum specs
Intel i5 or equivalent
GTX 770 or equivalent
8 GB RAM
64 KB disk space
That makes me laugh. 64kb space. But still needs 8gb of RAM and an i5.
can confirm i used to burn snes roms on floppy
a lot of the textures in minecraft are already based on each other, so i'd be curious how efficient you can make that
It's not clear if dynamic linking is allowed or not (considering it's something you really have to go out of your way to avoid), which is a big difference.
I was also going by some modified Raylib examples (+bindings, Linux, so size is influenced by that) I already had compiled, 1,372,160 bytes for the 2D one (no textures/sounds, just collision detection and some polygons). With my original comment I wasn't even thinking about how dynamic links could be counted for size, only that static linking could be smaller (which isn't even a guarantee).
EDIT: Actually, the 3D one (yaw_pitch_roll example with plane replaced with a vertex-painted office plant) is smaller after the binary is stripped.
Just the logic .so for one of my Godot projects is significantly big (761,856 bytes for something with ~250LoC) though that might be on the bindings or even my compilation settings.
I remember installing "PowerBuilder" onto my machine back in the day. It was 22 floppy discs to get the complete enterprise edition installed.
Most ready-to-use engines simply cannot compete in these kinds of challenges, they have too much "cruft". Simply exporting an empty project will result in a ~35mb executable.
Funnily enough, SDL might also not be worth it, as the .dll alone will blow the limit. So people will either have to use whatever native win32 API there are, or directx calls, or going with VGA, which will also look era appropriate.
To be fair, .kkrieger came out in 2004 :)
SliTaz might be an option, ~50mb image with Midori browser and other stuff; assuming the live image correctly detects and activates the wifi, it should be good enough
Just think how much more breathing room people coding for boot sector games would have
Maybe it's a regurgitate essence of a floppy disk by AI.
Whoever designed the poster didn't see a floppy disk on their lives.
I remember playing with MenuetOS in my computer repair class in high school. It was amazing even back then.
No, they're all floppy disks. Cause the platter was floppy, even if the disk wasn't.
Never heard of that one before, neat!
I've run it on a VM - it's not the most stable experience. Then again, it does run like lightning!
For chrome books, consider puppy Linux - it runs from a pen drive but can be installed.
Tiny footprint for an OS, and well optimised.
I can hear QUOD laughing at .kkrieger's pitifullly large filesize
quod is even more impressive at 64kb https://daivuk.itch.io/quod
That's enough for at least 22 copies of QUOD
Fair enough
Yeah .kkrieger a 3d FPS is only 96 KB and it achieved that with procedural generation.
I'm sure you could do it with a standalone runtime, but it will just be overhead compared to compiling directly to x86, at least for the purposes of this competition. I'm a fan of WASM for a lot of other applications tho