Demo scene: Zeer veel graphics uit klein bestand

[marcel-o]

Met wat surfen kwam ik dit tegen: http://www.pouet.net/prod.php?which=57070
slechts 8Kb groot (Norton gaat er van vanslag omdat t zo klein is )
maargoed, als je ziet wat er uit komt.
je hebt t zelfs kleiner

Hoe wordt zoiets geprogrammeerd?

Youtube voorbeeld van bovenstaande link.

Is dit t vervolg op die Demo's die je vroeger had op de C64?


_{Mocht t in t verkeerde hokje zijn gepost, hoor k t graag}

[ Voor 6% gewijzigd door marcel-o op 16-11-2011 23:00 ]

[NMe]

Hoe bedoel je, hoe wordt zoiets geprogrammeerd? Die graphics zijn niet van tevoren opgeslagen maar worden wel via een script/combinatie van formules gegenereerd. Ze zijn niet allemaal even eenvoudig maar het idee is vrij simpel: verzin een formule die een gaaf figuurtje tekent, pas de formule of een van diens variabelen aan voor het volgende frame, rinse and repeat.

[tiguan]

Jammer dat ik 't niet kan afspelen, je hebt er directx 9 voor nodig ofzo?

[Verwijderd]

Dit vind ik dan nog niet eens zo heel bijzonder. Je hebt hele spellen die in een vrij klein bestand gepropt worden op deze manier en die zien er helemaal niet zo slecht uit

Procedural generation.

[Verwijderd]

Komt behoorlijk overeen met milkdrop dat bij winamp zit. grote aanrader !!!

[RobIII]

NMe schreef op woensdag 16 november 2011 @ 23:01:
Die graphics zijn niet van tevoren opgeslagen maar worden wel via een script/combinatie van formules gegenereerd.

Niet alleen de graphics. Veel (soms zelfs alles) wat je hoort komt ook gewoon als sinusjes, white-noise en what-have-you uit formules rollen.

[ Voor 10% gewijzigd door RobIII op 16-11-2011 23:14 ]

[C.Hariri]

Door in assembly te programmeren, en een goeie compressor te gebruiken =).

[NMe]

RobIII schreef op woensdag 16 november 2011 @ 23:12:
[...]

Niet alleen de graphics. Veel (soms zelfs alles) wat je hoort komt ook gewoon als sinusjes, white-noise en what-have-you uit formules rollen.

Niet altijd, met modfiles kom je ook een heel eind zonder veel grotere files te maken. Al kan ik me voorstellen dat veel mensen in de demoscene het geluid inderdaad ook genereren.

C.Hariri schreef op woensdag 16 november 2011 @ 23:17:
Door in assembly te programmeren, en een goeie compressor te gebruiken =).

In assembly programmeren hoeft niet meer dan een paar bytes verschil te maken. Compilers van tegenwoordig zijn meestal beter in het optimaliseren dan jij dat bent als programmeur.

[ Voor 26% gewijzigd door NMe op 16-11-2011 23:18 ]

[RobIII]

marcel-o schreef op woensdag 16 november 2011 @ 22:55:
Is dit t vervolg op die Demo's die je vroeger had op de C64?

Vervolg? Is 't ooit gestopt dan? De demoscene is altijd actief geweest. Er zijn ook 4k (en nog kleinere!) compo's.

NMe schreef op woensdag 16 november 2011 @ 23:18:
In assembly programmeren hoeft niet meer dan een paar bytes verschil te maken. Compilers van tegenwoordig zijn meestal beter in het optimaliseren dan jij dat bent als programmeur.

Alleen, ik noem maar wat, loop-unrolls e.d. wil je nou nét niet hebben want dan past je demo niet meer in x Kb. Voor de échte die-hards in kleiner-dan-klein compo's is 't meestal wel assembly. Althans: dat was zo toen ik 't nog actief (of actiever) volgde. Dat is al een paar jaar wat minder.

Maak in een willekeurige taal eens een hello-world en compileer dat. In heel veel gevallen zal dat alléén al groter zijn dan 4k. Al is 't maar door de overhead van (overbodige zaken van) PE meuk etc.

[ Voor 66% gewijzigd door RobIII op 16-11-2011 23:26 ]

[killercow]

Voor content genererende algorithmen kun je denken aan L-systems, mandelbrots, of gewoon random spul

[.oisyn]

RobIII schreef op woensdag 16 november 2011 @ 23:19:
Alleen, ik noem maar wat, loop-unrolls e.d. wil je nou nét niet hebben want dan past je demo niet meer in x Kb.

De gebruikelijke compilers kunnen ook gewoon optimizen voor code size hoor

[C.Hariri]

In assembly programmeren hoeft niet meer dan een paar bytes verschil te maken. Compilers van tegenwoordig zijn meestal beter in het optimaliseren dan jij dat bent als programmeur.

dat wil ik dan nog wel eens zien. Performance wijs zal het idd niet veel schelen (max 10-15%) op zo'n 2x langere programmeertijd voor ASM, maar vergeet niet dat ze meerdere maanden de tijd hebben voor een demo.

Voor de grap moet je eens nagaan wat het kleinste bestand is dat je compiler genereert. Handmatig zal 1000bytes het minimum zijn (PE32 header); en dan nog 50 bytes voor wat instructies. Plek zat hoor.

Zal met een hogere programmeertaal niet zo snel lukken. Wellicht een kleine challange : D?

[Matis]

killercow schreef op woensdag 16 november 2011 @ 23:24:
Voor content genererende algorithmen kun je denken aan L-systems, mandelbrots, of gewoon random spul

Mandelbrots zijn gaaf. Paar regeltjes code. GUI er bij, wat click-events et voila. Plezier tot in het einde der tijden

[.oisyn]

C.Hariri schreef op woensdag 16 november 2011 @ 23:28:
Voor de grap moet je eens nagaan wat het kleinste bestand is dat je compiler genereert.

Maar dat is gewoon een kwestie van de juiste compiler en linker settings gebruiken. Je wil uiteraard niet de standaard lib meelinken, dus je zal een alternatief entry point moeten coden, en poef, toen was het ineens niet zoveel meer.

[RobIII]

.oisyn schreef op woensdag 16 november 2011 @ 23:31:
[...]

Maar dat is gewoon een kwestie van de juiste compiler en linker settings gebruiken. Je wil uiteraard niet de standaard lib meelinken, dus je zal een alternatief entry point moeten coden, en poef, toen was het ineens niet zoveel meer.

Nee ok; maar als 't op 't scherpst van de snede gaat en 't echt op een paar bytes komt wordt (althans: werd) er toch vaak teruggevallen op 't schrijven in assembly (danwel handmatig tweaken van delen van higher-level code op assembly niveau).
Ik heb 't niet over de "monster" demo's van, zeg, 64k of meer natuurlijk maar echt over de 1k, 4k etc. compo's.

[ Voor 8% gewijzigd door RobIII op 16-11-2011 23:34 ]

[C.Hariri]

Correctie van mijn vorige claim (1000 bytes);
http://www.phreedom.org/solar/code/tinype/

133 bytes voor een werkbare executable (NT -> win2k), dat gaat je echt niet lukken met een hogere programmeertaal hoor

[ Voor 6% gewijzigd door C.Hariri op 16-11-2011 23:36 ]

[.oisyn]

Bottom line is dat de VC++ 2005 linker nog steeds in staat is een executable van 468 bytes te produceren volgens dat voorbeeld, wat al veel minder is dan jij in je eerste reactie deed vermoeden (toen had je het nog over 1000 bytes als je geen linker gebruikt).

Het is dus een kwestie van een andere linker gebruiken, die bijv. geen nutteloze 16 bits DOS stub genereert, en dan kun je je code gewoon door een C++ compiler heen halen en hoef je je niet te beperken tot asm.

Ja, natuurlijk zal asm ook wat schelen. Maar UPX scheelt nog meer.

[ Voor 5% gewijzigd door .oisyn op 16-11-2011 23:44 ]

[Wolfos]

Hier kan je een klein stuk code zien dat graphics genereert in GLSL:
http://mrdoob.com/projects/glsl_sandbox/

Kan zijn dat de site alleen werkt onder Chrome, hij is nogal HTML5 heavy.

[C.Hariri]

UPX moet zelf ook nog een hele boel zooi naar je exe schrijven, namelijk de decompressie code , en die is tamelijk groot, loont uiteraard wel voor een groter bestand.

>( overigens moet je asm niet als een beperking zien. blijft een prachtige programmeertaal. af en toe wat geklooi is altijd leuk, en je hebt altijd wel wat onvolkomendheden die door de c++ compiler heenkomen die je dan met inline asm kan verbeteren (meestal niet, tegenwoordig allemaal geen tijd voor...).

[ Voor 48% gewijzigd door C.Hariri op 16-11-2011 23:57 ]

[RobIII]

C.Hariri schreef op woensdag 16 november 2011 @ 23:47:
en die is tamelijk groot

Ik meen ~2kb

[.oisyn]

C.Hariri schreef op woensdag 16 november 2011 @ 23:47:
UPX moet zelf ook nog een hele boel zooi naar je exe schrijven, namelijk de decompressie code : D, en die is tamelijk groot, loont uiteraard wel voor een groter bestand.

Het ging hier over intro's, niet over wie de kleinste penis heeft . Voor een 4k entry kan UPX best lonen.

[ Voor 5% gewijzigd door .oisyn op 16-11-2011 23:51 ]

[Don Kedero]

Farbrausch, The Product vind ik een hele straffe; 64 Kbyte 15 min + plezier aan beeldmateriaal en muziek.

Wikipedia: Farbrausch
http://www.theproduct.de/

[marcel-o]

bedankt voor de uitleg hier en daar.
Die Farbrausch ken k idd.. was ff weggeëbd.
maar toch vind ik t bijzonder dat in bv 4Kb dit gemaakt kan worden, incl geluid.. enz
is voor mijn gpu veel te zwaar, het youtube filmpje zegt wel veel!

Ben wel nieuwsgierig naar het script. is dat te extraheren oid?

[ Voor 19% gewijzigd door marcel-o op 19-11-2011 23:01 ]

[RobIII]

marcel-o schreef op zaterdag 19 november 2011 @ 23:00:
bedankt voor de uitleg hier en daar.


Ben wel nieuwsgierig naar het script. is dat te extraheren oid?

Als dat al zo was, en met alle respect, geloof me; daar ga je als leek geen hout van begrijpen. Kun je net zo goed naar een chinese tekst of formules die ze bij de LHC gebruiken kijken

[C.Hariri]

code:

MOV ECX,DWORD PTR DS:[EDX]
MOV DWORD PTR SS:[EBP-C],ECX
MOV EAX,DWORD PTR SS:[EBP-C]
SHR EAX,7
AND EAX,0FFF
MOV DWORD PTR SS:[EBP-8],EAX
MOV EAX,DWORD PTR SS:[EBP-C]
SHR EAX,13

^ dit stuk code kwam ik vandaag tegen. Gegenereerd door de MSVC++ (2010) compiler...

hier een optimalisatie:

code:

mov ecx, [edx]
mov [ebp-c], ecx
mov eax, ecx
shr eax, 7
and eax, 0fff
mov [ebp-8], eax
mov eax, ecx
shr eax, 13

[ Voor 27% gewijzigd door C.Hariri op 23-11-2011 19:43 ]

[.oisyn]

Het is ten eerste een niet echt boeiende optimalisatie (voornamelijk betere instruction cache hit ratio door kleinere code), en ten tweede zie ik de relevantie met deze topic niet helemaal...

[ Voor 22% gewijzigd door .oisyn op 23-11-2011 23:27 ]

[curry684]

.oisyn schreef op woensdag 23 november 2011 @ 22:08:
Het is ten eerste een niet echt boeiende optimalisatie (voornamelijk betere instruction cache hit ratio door kleinere code)

En 10 tegen 1 een slechtere cache hit ratio in de omliggende code omdat een compiler daar wel het overzicht op houdt en een handmatige assemblerbakker niet.

[AtleX]

Don Kedero schreef op donderdag 17 november 2011 @ 15:26:
Farbrausch, The Product vind ik een hele straffe; 64 Kbyte 15 min + plezier aan beeldmateriaal en muziek.

Wikipedia: Farbrausch
http://www.theproduct.de/

Wel wat groter dan 4KB, maar fr-025 is de beste demo die ik rond 2003/2004 gezien heb.

[jeroen3]

Het is zo klein omdat er geen bitmaps en patterns in zitten opgeslagen. Het zijn puur gegenereerde graphics uit een formule.

[M2M]

Iets recenter is, als ik me niet vergis, de 96? KB game. http://www.theprodukkt.com/kkrieger. Niet zo klein als een 4K demo, maar wel degelijk een stukje knap werk.

[Wolfboy]

.oisyn schreef op woensdag 16 november 2011 @ 23:42:
Ja, natuurlijk zal asm ook wat schelen. Maar UPX scheelt nog meer.

Naar mijn weten schrijven de meeste mensen in de demo scene de code tegenwoordig gewoon in een hogere taal (e.g. C) en optimaliseren daarna de gegenereerde assembly met de hand om nog wat ruimte te besparen.

Alles puur in Assembly schrijven is vaak gewoon niet zinnig. Compilers zijn met "-Os" redelijk efficient, zeker bij de 16k+ executables heeft het vaak niet veel nut meer.