pouët.net

Hellmood, qkumba, and I are happy to present a new resource for coding tiny productions:

http://www.sizecoding.org/

It contains information and resources for both newbies and veterans interested in the black art of x86 sizecoding (ie. making 256b or smaller productions for x86 platforms). Guides for working with the screen, outputting audio, thinking in terms of optimizing for size (and nasty size tricks), and an FPU tutorial are all there. Lists of helpful external resources are also provided, and we also have a "Case Studies" section that shows how some programs were size-optimized, and the thinking behind the decisions made. Being a wiki, we encourage anyone to contribute; all you need to do is register an account.

The site was partially motivated by the "tiny toolbox" thread on pouet, so we thank all of you for inspiration. It was also inspired by the recent ressurection of in4k -- you guys rock!

Here's some quick answers to questions I think you'll ask:

Why did you stand up a new wiki instead of contributing to in4k? in4k is wonderful, but it's a different target audience than sizecoding. in4k is for all platforms and covers 1k and larger. www.sizecoding.org is for x86 platforms only, and targets 256b and smaller.

Why did you make this a wiki, and not github? Because a wiki has the lowest barrier to entry and we wanted to encourage people to contribute. ("just submit a pull request" is more setup work than using a wiki.) For those worried about what happens if I get hit by a bus, hellmood and a few others have access to weekly backups of the site.

Why doesn't this support sceneid integration? Because non-sceners may want to register and contribute. Also, I'm not entirely sure how to get sceneid working on a php mediawiki site. Contact me offline if you feel sceneid integration is important and are willing to implement it.

Congrats for a job well done!
I can vouch for this as a rookie - the material herein has already helped me quite a bit with 'Sorry Ass'. ;)

Nice stuff :)

<dick> I long for the days when this was common knowledge </dick>

Nice job Trixter, as usual!

Awesome stuff. Thanks for giving me a reason to fix up the ol' 486! Totally gonna play around with this tonight.

Nice :-))

Excellent startup for a tinytro coding-wiki. I was pleased to see this. I'll read it when I get time. I love that you have a section of case-studies. I might even contribute to it if I get motivated.
Think its more comfortable to read if the commenting are carved out and descriptions are made in the Times.. font (and not just directly pasted from a commented .asm file). Anyways, great work!

If it's any consolation, <syntaxhighlight lang=nasm> works, so the listings are fairly easy to read/view. (In fact, that's the first extension I tested, since the wiki would have been seriously irritating without it)

niiiiiiice :)

That's pretty good stuff. Nice work

Nice initiative trixter.
I think I saw you were inspired byt this post http://www.pouet.net/topic.php?post=509924 for the loop twice and loop three times tricks. You mention e Rrrola for cccd trick, why not mention me for the loop twice and loop three times trick in return please ?

Doesn't have to be mutually exclusive :)

I don't feel it's important but I can get it working easy :)

Super cool. The content already in the wiki is very well written :)

Because the loop twice/thrice tricks were also from Rrrola, if you check the sources of "Symetrie" and "Puls" from 2007.

The wiki isn't about crediting the first use of every single trick, but rather about promoting sizecoding through sharing information and resources. If there are any edit wars over "first use credits", I will revert them and ban the offending user.

And an extra thumb up for the no-bully policy.

My only grip is the wiki markup; so use to markdown now. :p

good work!

i dont like the wiki format. think the new format we adopted for in4k is more flexible, spam free and future proof. but it's your call.

regarding integration with in4k, i agree the target is slightly different, but we could also rename the in4k github group and/or in4k site to tinyintros or sizecoding and include also resources for all tiny size code. but it's up to you.

i'll atleast for sure add a reference to your site on in4k repo somewhere :)

I think that cloning a repo and submitting pull requests is too much setup work for someone who just wants to contribute a little bit of info, especially if they're on a mobile device and just want to submit a correction. We will always differ on that point.

I'm flattered by the offer to integrate with in4k, but I don't remember asking? (Maybe you read "integrate with sceneid" and thought I meant in4k?) in4k and sizecoding have different methodologies and targets, so I don't think there's any pressing reason to integrate. If you want to cover sub-1k on in4k I certainly won't stop you; in fact, you can copy the info from sizecoding at any time, verbatim, as long as you honor the CC license.

ummmmm. so you mean sizecoding.org is _ONLY_ for sub 1k? if so, laaaaaaaaaaaame

...so this has nothing to do with in4k? Good old scene, always duplicating work just to be safe.

trixter: i just wrote what i wrote about in4k in reply to this paragraph of yours:



i dont mind at all if it remains a separate project. totally your call. just saying (as the guy who is not the owner of in4k but has been revamping it to 2016 on the past month) that we could easily work to integrate both into a single point of entry, if you guys ever feel it makes sense.

Perhaps, but GitHub doesn't require this:

actually in4k already had a small article about bytesize coding, so we might even just grab some info from sizecoding.com, update it a bit to 2016 and point to sizecoding.com for deeper insight.

yeah, github allows direct markdown edit nowdays. i mostly been using that to revamp in4k (hence the high commit count, one for each single page update)

Whatever you want to do with the sizecoding info is fine with us, that's why we wrote it. (I am curious what you mean by "update it to 2016" though, because we wrote the info this month and it's definitely representative of the state of the art in this area.)

We felt that focusing sizecoding.org to x86+256b and smaller gave us the opportunity to hone in on a very specific area. In our eyes, it really is a different discipline than 4k coding (the most obvious differences being no opportunity for compression, no compilers, no shaders or GPU acceleration). If you're wondering why we stood it up instead of contributing to in4k, that's why. It was because we felt there wasn't that much overlap, and was definitely not meant as a slight or anything.