4KB introt

  • Keskustelun aloittaja Keskustelun aloittaja -SD-
  • Aloitettu Aloitettu
Miten on sallitaanko noissa nykyään nykyaikaisten GPU:iden täysimääräinen hyödyntäminen (CPU:n sijasta) kun jos sallitaan sen luulisi vaikuttavan merkittävästi saavutettavaan visuaaliseen lopputulokseen (GPU sisälttä jo valmiiksi paljon sellaista jonka CPU toteutuksessa joutuu ohjelmoimaan sen 4kt rajan sisään).
 
DirectX:n valmisfunktioitahan noissa nykyään enimmäkseen käytetään, eikä mitään assembleria.
 
Ei näissä taideta nykyään mitään assembly kieltä käyttää. Rankkaa proseduraalista generointia GPU:lla. Matematiikka on aika kovassa roolissa. Monesti 4k intron käynnistys kestääkin tovin kun GPU alkaa raksuttamaan assetteja proseduraalisesta algoritmista. Elikkäs rankkaa DX/Vulkan/OpenGL kikkaa on nämä nyky demot.

Lähteenä erinäiset artikkelit joissa on käyty läpi nyky statusta 4k/64k introjen teosta. Voihan siellä joku masokisti vielä jotain x86 assembleria kirjoitella mutta päätyö on ihan täysin GPU ohjelmointia esimerkiksi DX rajapintaa käyttäen.
 
Nyt niinkuin jokainen tänne kirjoitellut voisi mennä itseensä ja kirjoittaa alle 4K ohjelman, valitsemallaan binääriksi käännettävllä kielellä. Täällä puuttuu täysin ymmärrys, mitä se kääntäjä laittaa siihen headeriin, miten tietkoneohjelmia käännetään ja mitä assemblerille voi tehdä (vastaus: kaiken).

Pakkaamaton 4k-ohjelma on 1000-2000 riviä, jos ei semmoisen koodin kirjoitus onnistu, olette ihan väärällä foorumilla.

En ole tehnyt yhtään 4k introa. Olen sen sijaan osallistunut lehtien kilpailuihin ja tehnyt alle 100 tavun matopelin. Voin tehdä 4k intron, jos joku maksaa 100€, kun se on päivän työ..
 
En tiedä mitä muistelin eilen mutta kaivoin nuita hyviä vanhoja linkkejä niin tottakai ASMilla tekevät. Oli jäänyt mieleen kun yleisesti kirjoittelevat monet C++:lla ja directX/OpenGL/softarenderöinnillä mockupin, mutta lopuksi tekevät ASMilla tottakai finaalin. Toki erilaisia toteutustapoja on miljoona koska nämä pienet sarjat on mustaa magiaa ja uusien tekniikoiden käyttöä/kehitystä.

Mitä hsalosen kommenttiin tulee niin veikkaan että jäisit yksin tälle foorumille jos foorumin vaatimuksissa olisi x86 assembly ja sujuvan 4k intron kirjoitus päivässä. Liekkö kukaan muu täällä edes tietää mitä ASM/Assembly/x86-asm tarkoittaa. :D
 
Vielä semmoinen kommentti, että 4K intro kyllä onnistuu, mutta visuaalinen ilme voi jäädä sille tasolle, että sillä ei voiteta kilpailuja. En ole artisti, olen koodari. Proseduraalisesti generoitu 3d on peruspullaa (ja marching cubeskin on nykyään vapaata riistaa), mutta se näyttää noin hyvältä vaan, jos on visuaalista silmää.

Tuolla esim. on NeHe:n vanhat OpenGL-tutoriaalit assemblerilla, ja ei siitä montaa tavua koodia tule funktioiden kutsusta:
GitHub - duncanspumpkin/NeHeNASM: NeHe's OpenGL Tutorial in NASM

Tässä sivusin kommentissani sitä, että on noita kompressio-ohjelmia, jotka pakkaavat EXE:n tai COM:in (ja purkavat sen muistiin), jolloin todellisuudessa saa lisätilaa. @PÌÎUW®[ªøËrhl¾ÇÌ°1¿¼ voi olla ihan oikeassa, että isompia introja (64K) tehdään jollain matalan tason kielellä (C?), että saadaan monimutkaisempia ohjelmia pienemmässä kehitysajassa.

4K on vain niin vähän, etten sotkisi mukaan mitään korkeamman tason kieltä. Ja jos siellä on assetteja (musiikkia, tekstuurinpalasia), niin nekin täytyy tunkea sekaan. Tilavaatimukset kasvaa varsinkin, jos pelaa 32-bittisillä muuttujilla, esim videomoodin asetus:
0: b8 13 00 00 00 mov eax,0x13
5: cd 10 int 0x10

(ei kukaan käytä VGA:ta enää, mutta esimerkkinä) :)
 
C:tä ja C++:aa käytetään kyllä ihan yleisesti 1k/4k introissa, ei sitä kamalasti koodia tarvita graffa-APIn kutsumiseen sen verran että saa minifoidut shaderit käännettyä ja piirrettyä jotain ruudunkokoisia quadeja raymarchaten per-pikseli tms. Toki sivussa pitää vähän kikkailla aina mutta jo kehityksen aikaisia työkaluja yms. varten on kiva olla muutenkin ylimääräistä toolingia ympärillä jotka vaikka preprosessorilla sitten karsii kun pitää saada julkaistua.

Sulautettujen maailmassakin tulee paljon vastaan C++:aa paikoissa joissa ROM/RAM mitataan kymmenissä/sadoissa kilotavuissa eikä siinä ole ongelmaa kunhan tietää mitkä subsetit lisää koodin tai ajonaikaisen stäkin/muiden allokaatioiden määrää.
 
C:tä ja C++:aa käytetään kyllä ihan yleisesti 1k/4k introissa, ei sitä kamalasti koodia tarvita graffa-APIn kutsumiseen sen verran että saa minifoidut shaderit käännettyä ja piirrettyä jotain ruudunkokoisia quadeja raymarchaten per-pikseli tms. Toki sivussa pitää vähän kikkailla aina mutta jo kehityksen aikaisia työkaluja yms. varten on kiva olla muutenkin ylimääräistä toolingia ympärillä jotka vaikka preprosessorilla sitten karsii kun pitää saada julkaistua.

Sulautettujen maailmassakin tulee paljon vastaan C++:aa paikoissa joissa ROM/RAM mitataan kymmenissä/sadoissa kilotavuissa eikä siinä ole ongelmaa kunhan tietää mitkä subsetit lisää koodin tai ajonaikaisen stäkin/muiden allokaatioiden määrää.

Tämähän oli täyttä roskaa. Onneksi oli paljon buzzwordeja.
 
Tämähän oli täyttä roskaa. Onneksi oli paljon buzzwordeja.
Buzzwordeista puheen ollen pitäisikin varmaan yrittää tehdä seuraava 4k Rustilla, siinä todennäkösesti riittää vielä haasteita :geek:

Jos oikeasti kiinnostaa tehdä muutakin kuin yrittää päteä foorumilla niin tuolla on yksi simppeli esimerkki mistä lähteä: GitHub - naavis/4k-Intro-Template: Template code for 4k demoscene intros. WebGL on ehkä helpompi alottamiseen, ei tosin kokemusta siitä introjen tekemisessä.
 
Buzzwordeista puheen ollen pitäisikin varmaan yrittää tehdä seuraava 4k Rustilla, siinä todennäkösesti riittää vielä haasteita :geek:

Jos oikeasti kiinnostaa tehdä muutakin kuin yrittää päteä foorumilla niin tuolla on yksi simppeli esimerkki mistä lähteä: GitHub - naavis/4k-Intro-Template: Template code for 4k demoscene intros. WebGL on ehkä helpompi alottamiseen, ei tosin kokemusta siitä introjen tekemisessä.

Pistäpä tänne alle 1k EXE, jonka olet tehnyt valitsemallasi ohjelmointikielellä, rust käy ihan hyvin. Ohjelma tulostaa ruudulle "Hei maailma!", konsoli käy ihan hyvin.

Ei pitäisi olla ongelma, jos kerran on asioista kokemusta. Muuten voisit lopettaa satunnaisten googletulosten väärintulkitsemisen.
 
360 tavua tuli kun tein tutorialin mukaan hello world ohjelman. 64bit ubuntu linux NASM käännetty. Vielä jäi 1k intro comboon roimat 600 tavua käyttämättä. Missä ilmoittaudutaan?

Tätähän piti alkaa reenaan.

:D
 
Tämmöisiä löytyi: The Crinkler executable file compressor EXE compressor.
Crinkler is an executable file compressor (or rather, a compressing linker) for Windows specifically targeted towards executables with a size of just a few kilobytes. As of 2015, it is the most widely used tool for compressing 4k intros.

[Demoscene] Crinkler: Under the Hood of the Best 4k Exe Compressor


Ovat onnistuneet tuolla pakkaamaan jopa 30kb kokoisia exejä alle 4k. Ilmeisesti tuo on osa taikaa mitä tekevät. Itse Crinkler vie 220 tavua eli pakattu EXE + 220 tavua on lopullinen koko joka ajetaan.

One of the nice things with Crinkler is the size of its decompressor: around 220 bytes which is perfect when you have to embed it in a 4k intro.

If you want to learn more about the secrets of Crinkler, how to code crinkler-friendly 4k intro (the smaller asm code is not always the best candidate for better compression under crinkler…), just read this detailed article written by xoofx, a member of the french demogroup FRequency:

Crinkler secrets, 4k intro executable compressor at its best
 
360 tavua tuli kun tein tutorialin mukaan hello world ohjelman. 64bit ubuntu linux NASM käännetty. Vielä jäi 1k intro comboon roimat 600 tavua käyttämättä. Missä ilmoittaudutaan?

Tätähän piti alkaa reenaan.

:D

Windowsisssa saa vieläkin pienemmäksi, kun kääntää konsoliohjelmana NASM:illa. Silti, hienosti tehty. Koko harjoituksen tarkoitus oli näyttää, että kääntäjä laittaa sinne roskaa, ja korkeamman tason kielillä sitä roskaa on enemmän. Korkeamman tason kielillä siellä voi olla jopa garbage collector mukana exessä..

Olen erittäin positiivisesti yllättynyt, että joku tekee jotain argumenttiensa eteen ja luen viestisi tarkemmin jatkossa. Tämähän meni erittäin hienosti.

Tämmöisiä löytyi: The Crinkler executable file compressor EXE compressor.


[Demoscene] Crinkler: Under the Hood of the Best 4k Exe Compressor


Ovat onnistuneet tuolla pakkaamaan jopa 30kb kokoisia exejä alle 4k. Ilmeisesti tuo on osa taikaa mitä tekevät. Itse Crinkler vie 220 tavua eli pakattu EXE + 220 tavua on lopullinen koko joka ajetaan.

Joo, tämä on se huijaus, paitsi oman aikani tuotokset olivat Lempel-Ziv -johdannaisia, nyt käytetetään kehittyneempiä pakkausmenetelmiä. Tulokset voi vaihdella, datan entropian mukaan. Siinä 30kb EXE:ssä on ollut paljon tyhjää/toistuvaa tietoa.

Tämän takia pyysin sitä alle 1k tuotosta, kun tuolla voi isonkin klöntin saada alle 4k. Se ei silti ole se hopealuoti, ratkaisu kaikkeen - ja jos ei itse osaa koodata assembleria yhtään, niin et sinä tuota alle 1k saa Windowsissa korkean tason kielelläsi - vain, koska usko on kova. Taidot tulee sitten perässä.
 
Windowsilla jostain syystä omista hello world example softista tulee yli kolmen kilotavun pommeja kun käännän NASM. Linuxilla FASM olen saanut 160 tavuun. No ehkä tästä voisi tehdä oman aiheen tänne jossain vaiheessa jossa käytäisiin keskusteluja. Meikäläisellä ei vielä kovin suurta hajua ole mitä kääntäjät tekevät eri alustoilla.

C++ perus hello world koodi kääntyy g++ -O3 lipulla 9,1kB exeksi.
Koodi:
#include <iostream>
using namespace std;
int main() {
    cout << "Hello world!" << endl;
    return 0;
}

Koodi:
; FASM example code

format ELF executable 3
entry start
;================== code =====================
segment readable executable
;=============================================
start:
 
        mov     eax,4             ; System call 'write'
        mov     ebx,1             ; 'stdout'
        mov     ecx,msg           ; Address of message
        mov     edx,msg_size      ; Length  of message
        int     0x80              ; All system calls are done via this interrupt
 
        mov     eax,1             ; System call 'exit'
        xor     ebx,ebx           ; Exitcode: 0 ('xor ebx,ebx' saves time; 'mov ebx, 0' would be slower)
        int     0x80
;================== data =====================
segment readable writeable
;=============================================
msg db 'Hello world!',0xA
msg_size = $-msg
HexDump linux 64bit toimivasta hello world ohjelmasta FASM:
Koodi:
00000000  7f 45 4c 46 01 01 01 03  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 03 00 01 00 00 00  74 80 04 08 34 00 00 00  |........t...4...|
00000020  00 00 00 00 00 00 00 00  34 00 20 00 02 00 28 00  |........4. ...(.|
00000030  00 00 00 00 01 00 00 00  74 00 00 00 74 80 04 08  |........t...t...|
00000040  74 80 04 08 1f 00 00 00  1f 00 00 00 05 00 00 00  |t...............|
00000050  00 10 00 00 01 00 00 00  93 00 00 00 93 90 04 08  |................|
00000060  93 90 04 08 0d 00 00 00  0d 00 00 00 06 00 00 00  |................|
00000070  00 10 00 00 b8 04 00 00  00 bb 01 00 00 00 b9 93  |................|
00000080  90 04 08 ba 0d 00 00 00  cd 80 b8 01 00 00 00 31  |...............1|
00000090  db cd 80 48 65 6c 6c 6f  20 77 6f 72 6c 64 21 0a  |...Hello world!.|
000000a0

ASM ohjelma käyttää 32bit rekistereitä, mutta en tiiä merkkaako kokoon paljoa. :) 64bit rekisterit olisivat rax, rbx, rcx, rdx kaiketi.

E: Ei tästä sen enempää. Jatketaan intro linjalla.
 
Viimeksi muokattu:
Pistäpä tänne alle 1k EXE, jonka olet tehnyt valitsemallasi ohjelmointikielellä, rust käy ihan hyvin. Ohjelma tulostaa ruudulle "Hei maailma!", konsoli käy ihan hyvin.
Siiiiiis vaikka toi pasteamani intro template tuottaa ihan suoraan C++ kääntäjän läpi menevästä koodista n. kahden kilon pakatun binäärin, joka siis luo ikkunan, hakee GL-kontekstin ja rendaa tyhjän quadin passthrough shadereilla (jotka binäärissä mukana) + tuet yksinkertaiselle äänen tuottamiselle. Voin testata vielä kunhan pääsen oikean koneen ääreen.

Rustia en ole käyttänyt itse missään kokokriittisessä koskaan mutta näemmä sillä pääsee lähelle, tosin melko rumaa kikkailua: main is usually a function: 151-byte static Linux binary in Rust Nimenomaan olisi hienoa tietää kuinka pitkälle Rustin tyyppijärjestelmän konseptit taipuu vaikkapa embedded-käytössä ennen kuin alkaa näkyä overheadia ajonaikaisessa tai kooditilan muistinkäytössä (ts. ei mitään unsafe-blokkeja joka paikassa).

C++:n kanssa on voinut käyttää esim. smart pointtereita todella pienissäkin ympäristöissä, tosin itse implementoituja vrt. STL. Osa optimoituu ulos käännösaikana suoraan ja lopun overheadi ei parhaimmillaan eroa mistään manuaalisesta allokaattorin kutsumisesta. Ja toki pitää käytännössä tässäkin osata assembleria (ja tarkastella kääntäjän outputtia välillä) vaikka sitä ei varsinaisesti paljoa kirjoiteta, pl. optimoinnit primitiivisempien suorittimien kanssa, moderneilla vehkeillä intrinsincit riittää esim. vektorilaskennassa tosi pitkälle.

Windowsilla jostain syystä omista hello world example softista tulee yli kolmen kilotavun pommeja kun käännän NASM. Linuxilla FASM olen saanut 160 tavuun. No ehkä tästä voisi tehdä oman aiheen tänne jossain vaiheessa jossa käytäisiin keskusteluja. Meikäläisellä ei vielä kovin suurta hajua ole mitä kääntäjät tekevät eri alustoilla.

C++ perus hello world koodi kääntyy g++ -O3 lipulla 9,1kB exeksi.
Koodi:
#include <iostream>
using namespace std;
int main() {
    cout << "Hello world!" << endl;
    return 0;
}
Ihme että edes noin pieneksi. C++:n stream-I/O on melko herkkä binäärin bloattaamiselle (ja muutenkin designiltään sellainen että usein suorilta bannattu codebaseista), samaten ihan STL containerit. -Os saattaa myös tuottaa pienemmän binäärin kuin O3.
 
Viimeksi muokattu:
Siiiiiis vaikka toi pasteamani intro template tuottaa ihan suoraan C++ kääntäjän läpi menevästä koodista n. kahden kilon pakatun binäärin, joka siis luo ikkunan, hakee GL-kontekstin ja rendaa tyhjän quadin passthrough shadereilla (jotka binäärissä mukana) + tuet yksinkertaiselle äänen tuottamiselle. Voin testata vielä kunhan pääsen oikean koneen ääreen.

Rustia en ole käyttänyt itse missään kokokriittisessä koskaan mutta näemmä sillä pääsee lähelle, tosin melko rumaa kikkailua: main is usually a function: 151-byte static Linux binary in Rust Nimenomaan olisi hienoa tietää kuinka pitkälle Rustin tyyppijärjestelmän konseptit taipuu vaikkapa embedded-käytössä ennen kuin alkaa näkyä overheadia ajonaikaisessa tai kooditilan muistinkäytössä (ts. ei mitään unsafe-blokkeja joka paikassa).

C++:n kanssa on voinut käyttää esim. smart pointtereita todella pienissäkin ympäristöissä, tosin itse implementoituja vrt. STL. Osa optimoituu ulos käännösaikana suoraan ja lopun overheadi ei parhaimmillaan eroa mistään manuaalisesta allokaattorin kutsumisesta. Ja toki pitää käytännössä tässäkin osata assembleria (ja tarkastella kääntäjän outputtia välillä) vaikka sitä ei varsinaisesti paljoa kirjoiteta, pl. optimoinnit primitiivisempien suorittimien kanssa, moderneilla vehkeillä intrinsincit riittää esim. vektorilaskennassa tosi pitkälle.


Ihme että edes noin pieneksi. C++:n stream-I/O on melko herkkä binäärin bloattaamiselle (ja muutenkin designiltään sellainen että usein suorilta bannattu codebaseista), samaten ihan STL containerit. -Os saattaa myös tuottaa pienemmän binäärin kuin O3.

Siiiiiis kun en ole ollenkaan varma, oletko vaan opetellut 50 taikasanaa, etsinyt kivoja saitteja googlella ja oma ohjelmointitaso on mallia peruna. Siksi en mielelläni näkisi sinua neuvomassa muita.

Pääsitkö jo oikean koneen ääreen, vai onko nekin vaan googlessa?

edit: tässä ja muissa postauksissani on tarkoituksena, että teet mahdollisimman helpon ja vähätöisen esimerkin, joutuen kuitenkin vähän soveltamaan, että perustietämys löytyy. Nyt on mennyt "Hei maailmassa!" jo melkein viikko, mutta jargonin suoltaminen jatkuu..
Voin keksiä helpon esimerkin, jossa on GL-pintojakin, jos se on siitä kiinni.
 
Viimeksi muokattu:
Siiiiiis kun en ole ollenkaan varma, oletko vaan opetellut 50 taikasanaa, etsinyt kivoja saitteja googlella ja oma ohjelmointitaso on mallia peruna. Siksi en mielelläni näkisi sinua neuvomassa muita.
Joo mä oon opetellut 50 taikasanaa jotta voin trollata tehokkaammin nettifoorumilla :kahvi:

Pääsitkö jo oikean koneen ääreen, vai onko nekin vaan googlessa?

edit: tässä ja muissa postauksissani on tarkoituksena, että teet mahdollisimman helpon ja vähätöisen esimerkin, joutuen kuitenkin vähän soveltamaan, että perustietämys löytyy. Nyt on mennyt "Hei maailmassa!" jo melkein viikko, mutta jargonin suoltaminen jatkuu..
Voin keksiä helpon esimerkin, jossa on GL-pintojakin, jos se on siitä kiinni.
Heitit typeriä kommentteja atk foorumilla ja oikein viikko mennyt että tulee vastaus? Voit oikein armosta keksiä toisen esimerkin? :lol:

Ei valitettavasti ole mäkillä PE binäärejä tuottavaa softaa mutta virtuaalikoneessakin oli näköjään jostain syystä msvc asennettuna. Tossa on joku alle 500 tavun binääri joka kutsuu win32 MessageBoxia ja tekee turhan allokaationkin: Dropbox - juuh.exe

Olisi mennyt pienempäänkin ts. tossa on turhaa kamaa vielä mukana mutta en viitsinyt varttia kauempaa uhrata typerään todisteluun - varttikin oli jo liikaa. Sitä paitsi mistä tiedät etten ole vain etsinyt jotain "smallest binarya" Googlella :confused:

Mun pointti alusta lähtien oli että 4k:n tekeminen fiksuilla työkaluilla ei ole mikään niin maailman kahdeksas assemblyihme niin kuin moni luulee (vaikka skilliä ja ideaa luonnollisesti tarvitaan ja voittajat on luonnollisesti jumalasta seuraavia skenepartoja). Voit ihan omin kätösin toistaa ton ihmeen: kloonaa aiemmin linkattu projekti, avaa Visual Studiolla (2017 on ihan riittävä, Communityn saa ilmaiseksi) ja käännä binääri release-asetuksilla.
 
Viimeksi muokattu:
Tästä hyvää lukemista, jos oikeasti kiinnostaa "pienin x"-turhuus.
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux
Huomatkaa että tämä on jo 18 vuotta vanha juttu, niin en tiedä kuinka hyvin enää pätee, silti erittäin kiinnostava lukea.

EDIT: laitetaan tähän vielä vähän lisää kommentteja:
Crinkleristä julkaistiin 2-versio 1k-tuella juuri 2 vuotta sitten assyjen aikana.
ja 4k:t on vaan parantunut vuosi vuodelta.
Yksi mikä jäi muistiin oli tämä: 99 Beers by Siffo
 
Viimeksi muokattu:

Statistiikka

Viestiketjuista
261 472
Viestejä
4 539 051
Jäsenet
74 803
Uusin jäsen
Mäntyvirta

Hinta.fi

Back
Ylös Bottom