otroliga 64kb?

Ingen aning.
Jävligt coolt iaf.

Det står på sidan.

Edit: farbrausch är grymma!

Jag håller på med en sådandär demo, med ljud och allt, fast den är bara typ 5sek lång hittils
Exefilen är typ 55kB nu, med musik blir det typ 65kB...

Det kallas optimering, något som MS skulle behöva lära sig.

Om dom gjorde sådär med windows skulle alla klaga på att dom behövde 3 gig temporära filer och att det skulle ta 15 minuter att starta windows.

Edit-
Fressten kallar man det komprimering

om spelutvecklara gjorde sådär skulle spelen ligga på disketter fortfarande och inte 3-4 skivor

Komprimering handlar om att då har du något som du sedan krymper, här har du optimerat din programmering till att inte ta så mycket plats och genererar all den stora mängd som du sedan ser. Att kalla det komprimering är inte riktigt rätt, det handlar om optimerad programmering.

mer godis: http://www.farb-rausch.com/

Det är inte bara programmeringen som är optimerad... och det är visst komprimering, iaf enligt dom.

Jag behöver knappast påpeka att datagenereringen tar tid, dvs processorkraft. Eller gör jag? Att satsa på att få programmet så lite som möjligt är knappast den enda typen av optimering. Om du nu fortfarande envisas med att dra paralleler till MS, så bör du veta att denna typ av "optimering" helt är ohållbar.

Visst är det så, men den komprimeringen är en viss form av optimering.

citerar från deras faq
with your technology you could compress a dvd to a floppy disk!
you got it all wrong. .the .product is not about compression, it's about generation. we can only "compress" data generated with our tool.

Nä, det behöver du inte.
Du har helt rätt i att storleksoptimering inte är något fullt så viktigt för MS då dom gör ett os som ex windows. Däremot är ju prestandaoptimeringar ganska viktiga, speciellt på kritiska delar som själva kärnan och vissa processer.

Varför skrev du då att det inte var komprimering?

.the .product bör väl dock satsa mer på storlek än prestanda? En klassisk tumregel är ju att mer kod ger bättre prestanda, mycket kod är knappast vad dom satsar på i .the .product

Den tumregeln har jag aldrig hört talas om.

Du måste ha fattat det totalt fel.

Grymt fett.
Men håller med denka om att det inte är prestandan dom satsar på, det framgår ju ganska tydligt

Ett exempel:

int main()
{
    int a = 0;    

    printf("\nDo you wish to show all steps of the fibonaccification? Yes(1)/No(0)\n>  ");
    scanf("%d", &yn);
    
    if(yn != 0 && yn != 1)
        return 0;

    while(1)
    {
        printf("\n\n\nEnter a number to be fibonaccied:\n>  ");
        scanf("%d", &a);
    
        if(yn != 0)
            printf("End result: %d", fib(a));
        else
            printf("Result: %d, %d steps", fib(a));
        x = 0;
    }
}

int fib(int a) 
{
    if(yn != 0)
        printf("Step %d: %d\n", x, a);
    x++;

    if (a==0 || a==1) 
        return 1;
    else
        return (fib(a-2) + fib(a-1));
}

Kolla i funktionen fib(). Där finns en if-sats som kallas varje gång funktionen körs, hade man däremot satt if-satsen tidigare och haft fiba() och fibb(), a som inte skrev ut stegen och b som gjorde det så hade det blivigt snabbare, men ca 25% mer kod.. liknande exempel finns om och om igen.
Detta gäller självklart inte alltid (ibland är det tvärtom), men jag menar att när man tar genvägar blir det ofta lättare för den som skriver koden, men inte för datorn.

För att dom inte tar en färdig bild eller låt och trycker ihop till liten plats utan att dom genererar bilderna och musiken. Men sen kanske min formulering var lite dåligt, fullt möjligt.

Sen bör väl tilläggas att dom vid faq använde "" på ordet compress, detta för att markera att det inte handlar om att komprimera ner någon slags film till liten storlek utan om att pga smart programmering trycka ihop det som genererar detta på så liten storlek som möjligt, men i och för sig med viss komprimering, och där används komprimering för att minska storleken på deras kod och data i filen. Men själva grunden är mycket effektiv programmering.

Nu pratade jag om MS, och för dom är inte storleksoptimering särskilt nödvändigt. Men som du säger är ju storleksoptimering i detta fall av största vikt då det just är själva målet att göra så bra demo på 64kB och då är det storleken som räknas.

Fibonacci kan faktiskt göras ännu snabbare genom att återanvända gamla tal och iterativ rekursion:

int fib(int a, int fib_1=1, int fib_2=0)
{
  if (a==0 || a==1)
    return fib_1+fib_2;

  return fib(a-1,fib_1+fib_2,fib_1);
}

Sådär helt appropå alltså

eeeeh. jo det brukar ju vara så... inte?

farb-rausch är för övrigt väldigt söta

dra gärna ner deras .avi konverteringar om eran dator inte orka med.

Aha, missförstod dig då, trodde du menade att dom inte komprimerade någonting alls (vilket dom gör med tex UPX)

Jo. Personligen tycker jag nog MS drar på lite för mycket på minnet, Win XP kräver (bör ha) egentligen otroligt mkt minne.

int fib(int a, int fib_1=1, int fib_2=0)
{
  if (a==0 || a==1)
    return fib_1+fib_2;

  return fib(a-1,fib_1+fib_2,fib_1);
}

Smart. Fast fibbonaci var bara ett exempel, använder det inte..

Det är så ganska ofta, faktiskt

och varför inte räkna ut konstanta fibtal på detta sätt?

#include <stdio.h>

template<int i> struct CFib
{
	enum { v = CFib<i-2>::v+CFib<i-1>::v };
};

template<> struct CFib<1>
{
	enum { v = 1 };
};

template<> struct CFib<0>
{
	enum { v = 1 };
};

int main()
{
	printf("%d\n", CFib<5>::v);
	return 0;
};

I vilket språk brukar man skriva dessa i?? asm, C, C++ ?

vad är ett fib tal ?

asm använder dom nog annars skulle dom bli ganska stora

Tal från Fibonacci-serien, a_(n+2)=a_(n+1)+a_n. a_0=1,a_1=1.
Alltså 1, 1, 2, 3, 5, 8, 13, ...

Asm/C/C++ är väl vanligast.