pouët.net

Hey all,

I'm looking for a collaborator on a Linux 4k (or maybe 1k) for @party this year. I'm also interested in starting (or joining) a US demogroup, if that's of interest to anyone (we're few and far between).

Things I'm good at:

C / x86 asm
sizecoding
mathematics
coder colors

Things I need help making:

shiny glsl shaders
musics (having fun working on a tiny softsynth)
getting dressed (but you don't need to help me with that)

I occasionally post things that I've been working on that I think are novel or interesting in some way on pouet which you can peruse [url=http://pouet.net/groups.php?which=10886]here[url]. Thanks for reading <3

Sorry for the broken bbcode

Out of curiosity: What makes size coding for Linux special compared to size coding for DOS or for Windows? What are the differences one has to respect?

There is no Crinkler for Linux.

there are of course some other tricks to use with linux

Getting dressed?!? Everyone knows the best demos are made with your pants off.

4k without crinkler and standard 3D libs? is that even possible?

Under Linux I suppose you can rely on stuff like GZIP and Bzip2 being installed so you can do similar things to CAB-dropping.

Also lzma, which should work on recent Debians / Debian-based at the very least. But AFAIK it's the only option as anything else will land you with the huge ELF header which you can't do without if you want anything that has to do with dynamic libraries.

Even using gcc -s -Os and sstrip will land you with a 1656 bytes executable for a simple printf("Fuck you, world\n") (yeah, I know I could really make that smaller by *not* using libc, but the point is kinda moot if you want to use, say, GL).

Of course, if there are better ways than that... I'd be very happy to read about it.

Awesome question. The absence of Crinkler is a big one, though as Gargaj points you, gzip is the standard answer to that problem (and its a pretty freaking good one). Obviously different binary formats make a big difference. ELF headers are big and klunky and that is a major problem (it gets worse if you're trying to work under 64 bit Linux). But again, there are work arounds...

Of course there are also advantages to writing sizecode under Linux too. Lots of shared libraries are standard (SDL, glib, etc.) and there are lots of standard programs (gzip, bzip2, python, gcc - but thats kind of cheating) under Linux. The result is a plethora of tricks that are impossible under windows.

The primary reason I'm interested in (and enjoying) writing sizecode under Linux is that it is a relatively unexplored area. There are some tricks that have already been discovered by myself and others. But I'm sure there is still plenty of great ideas that haven't been implemented yet!



Yes.



OpenGL is standard under Linux. There are actually some pretty respectable 1k and 4k prods under Linux. You should check it out :) The codebase I'm working on now can load a glsl shader and start dumping bytes to audio in 600 bytes on 64 bit Linux. That could probably be optimized down to around 500 bytes. Another 500-1k for the softsynth and I think there will be plenty of room for a decent 4k.

:-O
That is pretty damned impressive.

Its not bad :) We'll see how the softsynth turns out. I just need someone to help put it to good use!

Is there a GUI for your synth or is your future love forced to learn how to compose with hex bytes? :)

Not even I am that left-brained ;) There will eventually be a GUI, but it'll be a couple weeks before its finished.

Thanks for the answers!

orbitaldecay: As far as I know, 4klang can generate an ELF object, and the synth is open source. This can save you some time if you're in a hurry. Don't know about Linux, but under windows I had to take 1.6-1.8k of size into account for synth+music using 4klang. That's a lot, but I stuffed the music up a lot, never liked minimalistic songs :)

xTr1m: Thanks for pointing it out, I'll definitely have a look (especially if time starts running short) :) Looks like it builds fine on 32 bit Linux, but some hackery might be involved in porting it to 64 bit, haven't looked closely at it yet.

re: ELF header.. i thought this was common knowledge by now: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

It is indeed common knowledge. Hacking up ELF headers to squeeze out a few bytes has been done by a lot of folks. That example is so tiny because they don't use any dynamic linking, thus they're able to exclude several sections that usually use up a lot of space. It also means that its basically useless. Any *useful* ELF header is still bloated compared to a PE header.

Also, some of it no longer even works on x86-64, as the kernel will reject a ELF header with some of the hacks there.

orbitaldecay: i hope you will still release some dos-intro somewhere in the future :D

sensenstahl: Thanks buddy! Still waiting on your next one too :)

Hey! I am planning to attend @party this year, contact me at danguafer(a)silexars.com or add me on Facebook facebook.com/danguafer

I'd love to have a go at your synth, if it's somewhat reasonably easy to use. I'd ofcourse need to know a little about what data format you're expecting. I'm fairly decent at working in Renoise, and I've got my fair share of 4k tunes done in the past. I'm familiar with 4klang, Loonies 4k and a couple of other synths, so my main concern is actually if Renoise's zipped xml-structure would work for your needs. Not that I'm particularly afraid of using other DAWs, but some degree of usability would definitely work best.

Best way to make sure random people will be able to help you out, is to device a VSTi for your synth and have a built-in exporter. That way, any people using any DAW would essentially be able to provide music for your productions.

But once you've got a working synth and a somewhat decent/userfriendly aproach for composing, feel free to drop me a mail at punqtured at fnuque dot dk.

Wasnt there a musician looking for a group a few threads ago...?

match made in heaven!