I followed a link in an earlier post and found this gem:
http://www.theprodukkt.com/debris
You'll need a beefy system for it but it's sheer magic.
http://www.theprodukkt.com/debris
You'll need a beefy system for it but it's sheer magic.
180Kb Magic
Miscellaneous Forums/General Discussion/180Kb Magic Yes it is really artistic :)))
But my favorit is always "fr-08: .the .product" !
But my favorit is always "fr-08: .the .product" !
My personal fave was fr-025: the.popular.demo but there's no question that debris is an amazing achievement and deserves it's place as one of the top ten demos of all time.
@_33 : Indeed, but i didn't know the discussion was about the demo in that topic. And besides that, I'm sometimes just lazy.
The camera is outstanding in debris.
that was amazing! is everything done procedurally? My mind is really baffled.
There are tons of procedural things in there + the demo engine + the music player + camera works + shadow engine + speech synth (not in this one) + vocoder (not in this demo) + particle engine + .... + ...
The exe is probably packed with a special UPX like packer, so it might well be 400 - 600 KB in reality. But these guys are obviously very good.
They make their own tools to edit the textures, edit the sounds, edit the music score and sound effects. They make their own scene editor and their own scripting tool.... It's all specially tweaked to make very tiny executables that are auto sufficient. I mean, the exe contains it's own data storage where it contains all the bytecoded script to rebuild everything before it runs. That's why it takes so much time in the beginning.
Someone that programmed an 8-bit computer or is familiar with assembly language might understand the feasability of this, but it's insane work. Why I mention 8-bit computers is mostly because at the time, you had to do a lot with very little RAM or very little storage, so you had to find ways to do things that were small. Assembly language is also a good way to do fast and tiny programs.
The exe is probably packed with a special UPX like packer, so it might well be 400 - 600 KB in reality. But these guys are obviously very good.
They make their own tools to edit the textures, edit the sounds, edit the music score and sound effects. They make their own scene editor and their own scripting tool.... It's all specially tweaked to make very tiny executables that are auto sufficient. I mean, the exe contains it's own data storage where it contains all the bytecoded script to rebuild everything before it runs. That's why it takes so much time in the beginning.
Someone that programmed an 8-bit computer or is familiar with assembly language might understand the feasability of this, but it's insane work. Why I mention 8-bit computers is mostly because at the time, you had to do a lot with very little RAM or very little storage, so you had to find ways to do things that were small. Assembly language is also a good way to do fast and tiny programs.
Heh, I still make games for 8-bit computers ;)
And yes, those demos are rather impressive - specially if you know the kind of problems they face to do it...
But usually those demos are full of tricks, that (unfortunaly) cant possibly be used on a full-scale game.
Best thing I heard, are from the 8-bit scene: "if it's fast and looks good, it's a trick" :)
And yes, those demos are rather impressive - specially if you know the kind of problems they face to do it...
But usually those demos are full of tricks, that (unfortunaly) cant possibly be used on a full-scale game.
Best thing I heard, are from the 8-bit scene: "if it's fast and looks good, it's a trick" :)
Heh, did anyone see them shout out my name in the demo!?
Some fancy stuff going on there.
Some fancy stuff going on there.
Absolutely amazing that they manage to squeaze all of that into a measly 180KB. The music alone sounds like it ought to take up a lot more space than that.
This on still impresses the heck out of me too, though:
Omniscent, winner of the Mekka97 4k-Intro Compo.
ftp://ftp.mpoli.fi/pub/skene/DEMO/OTHER/SNC_OMNA.ZIP
(run SNC_OMNI.com in the zip)
Dating back to 1997, a mere 4095 bytes for a full flythrough of the first level of the 'Descent' FPS Game, including seemingly identical textures. It even plays music if your soundcard is supported.
This on still impresses the heck out of me too, though:
Omniscent, winner of the Mekka97 4k-Intro Compo.
ftp://ftp.mpoli.fi/pub/skene/DEMO/OTHER/SNC_OMNA.ZIP
(run SNC_OMNI.com in the zip)
Dating back to 1997, a mere 4095 bytes for a full flythrough of the first level of the 'Descent' FPS Game, including seemingly identical textures. It even plays music if your soundcard is supported.
yep awesome, thanks!
meh.
ftp://ftp.scene.org/pub/demos/groups/aardbei/aardbei_ptct.zip
Music by me, whole shebang in 64kb :P All sounds generated!
ftp://ftp.scene.org/pub/demos/groups/aardbei/aardbei_ptct.zip
Music by me, whole shebang in 64kb :P All sounds generated!
It's clever, but lets be realistic, it's not a 180k or 64k demo... If your computer had 180k or 64k it would never run. It's a 180k download, which (as already mentioned) is initially packed, this unpacks first and then proceeds to fill your memory and vid card up with more stuff.
Yes the textures are generated procedurally... however, they create a 512x512 (or whatever) bitmap weighing in at 1mb that gets dumped onto the vid card. It's basically a glorified line draw routine, ie, startpoint xy endpoint xy, fill in the rest.
Likewise with sounds, create a sine wave, add noise etc. It's very straight forward to then build a dirty big 44khz sample, the maths isn't that complicated to create some fairly meaty sounds, generally all you need are a couple of oscillators and a few filters, neither of which are particularly code heavy.
I'm not trying to take anything away from the scrumptiousness of this demo though, think it looks and sounds wonderful! It's just not as 180k as people seem to be making out.
Yes the textures are generated procedurally... however, they create a 512x512 (or whatever) bitmap weighing in at 1mb that gets dumped onto the vid card. It's basically a glorified line draw routine, ie, startpoint xy endpoint xy, fill in the rest.
Likewise with sounds, create a sine wave, add noise etc. It's very straight forward to then build a dirty big 44khz sample, the maths isn't that complicated to create some fairly meaty sounds, generally all you need are a couple of oscillators and a few filters, neither of which are particularly code heavy.
I'm not trying to take anything away from the scrumptiousness of this demo though, think it looks and sounds wonderful! It's just not as 180k as people seem to be making out.
CS_TBL: looks (and sounds) pretty nice!
.Rob. I don't believe the 64kb contests ever were about memory tho, purely about disksize. In the later years it's all about who has the most efficient precalc scripts and who has the most advanced generators. So, in a way you're right about the memory thing, but it's not relevant in this specific context. :P
yeah I concurr it was never about running in a certain amount of memory, just disk space. I still think it's pretty clever but I guess like anything once you know the techniques and have practiced them it's just a case of putting it all together.
really makes you laugh when you see developers saying DVD's are too small for them. The consoles only got 64Megs of RAM you fool! How can a DVD not be big enough?!?!
Because it's only due to the media (vfx, gfx, meshes, sfx) and the media tool chain works in a different way.
With the common way:
+ You faster get results, it's more natural and you're way more flexible.
+ Better communication with other apps.
+ Less setup calculation needed and so lower hardware ressources.
- Much larger files
With the common way:
+ You faster get results, it's more natural and you're way more flexible.
+ Better communication with other apps.
+ Less setup calculation needed and so lower hardware ressources.
- Much larger files
Depends on your content. The key-artifact of those 64kb intros is that the content can usually be described as mathematical. A textured sphere? Pure math, a 303 loop in music? Purely simple formulas. It gets bad when you actually want non-formule stuff in it. A human model already requires somewhat of a pre-fab table, and real samples of acoustic instruments are also huge. If a DVD is said to be not enough then I estimate -or rather: 'hope'- that they're filling it up with HD videos and other huge quality media. So, as long as a DVD is genuinely filled, I won't bother. Besides, whether you fill 1Gb or 4Gb .. it's still a DVD you need, you can as well fill it up completely.
Yep, that's exactly the issue. It depends on your content. With the common tools i can make every content i would like to do. With mathematical descriptions i can't as soon as i leave the borders of the underlying system.
o Plugging in your guitar, singing around and recording this, encoding it to ogg. Bump you're done. Try to interpret this with a synthesizer.
o Modelling an object with a sds modeller, alter this and that, paint on some normal maps. Export and whoosh your ready to go in a lot of engines.
o Draw a texture which also contains photo information. Export in a known format like a dxtc, again you're done.
Beside of the first case (were i haven't found any solutions so far) the others could be solved by sophisticated libs which you ship with the engine but a) how much processing time would it take to generate the content before startup and b) how large would this lib then be itself? The better it is the larger it would be.
As bandwith and storage space is growing, i don't see it happening a lot and you would really have to establish something like a standard so that it gets widely accepted and used.
I like the idea behind of these things (procedural libs and gfx/sfx/modell generative process, like the TE of werkkzeug for gfx) and it would be great especially for online content but i also do see the obstacles between a widely common usage.
o Plugging in your guitar, singing around and recording this, encoding it to ogg. Bump you're done. Try to interpret this with a synthesizer.
o Modelling an object with a sds modeller, alter this and that, paint on some normal maps. Export and whoosh your ready to go in a lot of engines.
o Draw a texture which also contains photo information. Export in a known format like a dxtc, again you're done.
Beside of the first case (were i haven't found any solutions so far) the others could be solved by sophisticated libs which you ship with the engine but a) how much processing time would it take to generate the content before startup and b) how large would this lib then be itself? The better it is the larger it would be.
As bandwith and storage space is growing, i don't see it happening a lot and you would really have to establish something like a standard so that it gets widely accepted and used.
I like the idea behind of these things (procedural libs and gfx/sfx/modell generative process, like the TE of werkkzeug for gfx) and it would be great especially for online content but i also do see the obstacles between a widely common usage.
yes, I agree that high quality models requires mroe space. It just feels like games are becoming very "bloated" in terms of space requirements.
Don't forget that:
a) you current monitor is probably bigger than the one you had when games were small
b) resolutions are now higher than when games were small
c) level of depth is now higher than when games were small
d) probably more stuff being a real model rather than a bumpy texture on a flat surface - I dunno tho, 3d is not my thing -
e) cutscenes are of DVD quality now
Everything grows, just look at the size of your current OS, compared to DOS6.
Retro systems also have fairly large games while still being small, only like 3..6 double sided disks orso, but:
- indexed color gfx, if it's 16 colors max then you can store 2 pixels in 1 byte
- lowres screens, like 320x160 or 256x192
- some games even have patternmodes, which could store 8x8 pixels in 16 bytes memory
- music is usually not sample based, but FM-based, or any other chip like the PSG or SID
- cutscenes used to be slideshows
So, all-in I'm not surprised today's stuff is big. In ten years time, a game could perhaps be 50Gb. Tho I do believe sooner or later there's going to be a limit somehow. Because at a certain point your eyes and ears can't distinguish any more details anymore. For the same reason, we still have 24bit color.. who needs 36bit anyway? Resolution: at a certain point monitors won't get bigger, meaning that the resolutions will match the smallest possible dot on the screen. Music formats aren't relevant.. that's just going to be streaming, perhaps multiple streams at the same time could be the norm for the future. Etc.
a) you current monitor is probably bigger than the one you had when games were small
b) resolutions are now higher than when games were small
c) level of depth is now higher than when games were small
d) probably more stuff being a real model rather than a bumpy texture on a flat surface - I dunno tho, 3d is not my thing -
e) cutscenes are of DVD quality now
Everything grows, just look at the size of your current OS, compared to DOS6.
Retro systems also have fairly large games while still being small, only like 3..6 double sided disks orso, but:
- indexed color gfx, if it's 16 colors max then you can store 2 pixels in 1 byte
- lowres screens, like 320x160 or 256x192
- some games even have patternmodes, which could store 8x8 pixels in 16 bytes memory
- music is usually not sample based, but FM-based, or any other chip like the PSG or SID
- cutscenes used to be slideshows
So, all-in I'm not surprised today's stuff is big. In ten years time, a game could perhaps be 50Gb. Tho I do believe sooner or later there's going to be a limit somehow. Because at a certain point your eyes and ears can't distinguish any more details anymore. For the same reason, we still have 24bit color.. who needs 36bit anyway? Resolution: at a certain point monitors won't get bigger, meaning that the resolutions will match the smallest possible dot on the screen. Music formats aren't relevant.. that's just going to be streaming, perhaps multiple streams at the same time could be the norm for the future. Etc.
Personally i would prefer comparing to AmigaOS instead of DOS6... ;O)
24bit are were already a border years ago. Try to do proper transitions between black and white. As soon as there is enough power we'll see more floating point precision for calculation inside and HDR displays outside.
And i also don't think that it will take ten years till 50gb are reached in games. Actually that's exactly what you already get with a dual layered blu-ray.
24bit are were already a border years ago. Try to do proper transitions between black and white. As soon as there is enough power we'll see more floating point precision for calculation inside and HDR displays outside.
And i also don't think that it will take ten years till 50gb are reached in games. Actually that's exactly what you already get with a dual layered blu-ray.
Sorry, I had to bring this on eback up, but 180K with ptocedural this and that, or how about 1K with, ehm... chocolate milkshake liquid sort of thingy in 1K with string chords playing in the background?
http://www.pouet.net/prod.php?which=32194
1K !!! 1024 bytes!!!!!
It's two minutes of madness! 120 seconds, so you can do the ratio on how many bytes per second, and the "worth it" factor, ie; worth every byte of it!
http://www.pouet.net/prod.php?which=32194
1K !!! 1024 bytes!!!!!
It's two minutes of madness! 120 seconds, so you can do the ratio on how many bytes per second, and the "worth it" factor, ie; worth every byte of it!
The best 1k competition were on the amiga bootblock, yay! 8O)
Nice fluid stuff.
Still, I think, even with these low figures that better sound&music could've been done for it.
Still, I think, even with these low figures that better sound&music could've been done for it.
farbrausch powa :)
Nice fluid stuff.
Still, I think, even with these low figures that better sound&music could've been done for it.
Still, I think, even with these low figures that better sound&music could've been done for it.
I highly doubt that CS_TBL, because basically what the guy did is call the MIDI system, and sent a couple of chords. Don't forget we only have 1024 bytes here, it's not like there's an abundance of room to design a sound interface. I tought the sound (music?) was fitting to the overall scenario, but repetitive. But you can't really do much in that filesize!
The fluid is probably a couple of shader algorythms.
I think it's quite impressive, and so does all the pouet members so far, and they usually don't post biased impressions.
Even then, even then..
For years I've been thinking about converting random data into sense making music. As 'random' data it could take the executable data itself, it's then up to the coder to generate music out of it.
<edit> Just a semi-relevant reference: http://www.pouet.net/prod.php?which=5427
The particles aren't random, they're the executable data.. :P
For years I've been thinking about converting random data into sense making music. As 'random' data it could take the executable data itself, it's then up to the coder to generate music out of it.
<edit> Just a semi-relevant reference: http://www.pouet.net/prod.php?which=5427
The particles aren't random, they're the executable data.. :P