pouët.net

Best 4k compiler

category: general [glöplog]
spooky re-wrote our intro into 100% asm
added on the 2008-08-29 22:57:59 by quisten quisten
teh futare si won?
added on the 2008-08-30 00:19:04 by delta delta
i use visual basic 4.
added on the 2008-08-30 00:23:47 by rmeht rmeht
It's too bad that crinkler is windows only. Although muhcno has recently been released, that makes linux a not-very-suitable target for 4ks. UPX and gzexe are the only options but they get nowhere near crinkler/muncho.

:(.

Maybe someday I'll ask jix for his compression routine and work on 'luncho'...
added on the 2008-08-30 02:52:57 by LiraNuna LiraNuna
Quote:
Don't listen to niels, he doesn't even like 4ks!


yeah never listen to me -- that's rule #1. i'll be the first to admnit i lost the touch of democoding over the past six years, but when it comes to the gritty details i'm there allright. so just stick with bb's comment, but always prevent to for strive full and often useless (on a short-term) comprehension of information that passes your comfort zone - it's either false or useless in your current timeframe.
added on the 2008-08-30 04:15:26 by superplek superplek
Quote:
the future of 4ks lies in shaders primarily


That's true. This is gonna be challenge for packers like crinckler cause they are heavily focused to packing code.

Using GLSL or HLSL adds lot's of string data and remove main focus from traditional code size optimizing.
added on the 2008-08-30 09:48:36 by blueflame blueflame
blueflame: heavily focused as in having one optional transform? :)
added on the 2008-08-30 10:36:30 by mentor mentor
i'm wondering:
since glsl will be compiled at runtime, wont it be possible (and smaller in terms of size) to store it in binary format, i mean already compiled???

or maybe each card have its own opcode format and it will break compatibility stuff ???
added on the 2008-08-30 11:14:17 by Tigrou Tigrou
I don't think it is possible to give it in binary form.
added on the 2008-08-30 11:19:35 by blueflame blueflame
Quote:

i'm wondering:
since glsl will be compiled at runtime, wont it be possible (and smaller in terms of size) to store it in binary format, i mean already compiled???

or maybe each card have its own opcode format and it will break compatibility stuff ???

Nope, it's not a good idea, this stuff is unspecified, and the api don't let you do that by the way (or not that I've heard of). But I think a code "deconstructor/reconstructor" which parse the original GLSL, discarding all unusefull data and renaming non-uniform variables to pack it in a sort of binary format might (might intented) win some place.

The question is : will it perform better than any general packer already there, shaders files got a lot a redundancy normaly...
added on the 2008-08-30 12:11:31 by Twinside Twinside
Currently i'm stuck with a 1k which is 200 bytes too much. Its just contains the minimal stuff (ogl initialisation+a shader)

the smallest init code i get takes 805 bytes , which left no so much place for others stuff


the opengl shader initialisation only takes a lot of bytes...
Code: p = ((PFNGLCREATEPROGRAMPROC) wglGetProcAddress("glCreateProgram"))(); s = ((PFNGLCREATESHADERPROC) (wglGetProcAddress("glCreateShader")))(GL_VERTEX_SHADER);



i check Metalwork source (which is d3d9 based) but seems even with pure asm + crinkgler dont let so much place for shaders...

I think writting a specific 1k exe compressor is the best
(like http://www.pouet.net/prod.php?which=50688) but have no fucking idea how to write this nor the algorythm to use (LZ ?, RLE? )

added on the 2008-08-30 12:55:11 by Tigrou Tigrou
Quote:
but have no fucking idea how to write this nor the algorythm to use (LZ ?, RLE? )

Yeah, a hybrid LZ/RLE packer like Pucrunch for C64 should be pretty good for 1Ks (small decompressor, appropriate compression ratio).
added on the 2008-08-30 13:04:22 by RufUsul RufUsul
I'm just reading this thread, i've never code with GLSL, i've just have a look what GLSL look what, and yes,

i believe that some kind of ownPreCompiled(compressed) code then decrompression system may work.

I believe if we got some kind of dict. and encoding /deconding process for some typical and usual words and expressions that it could save lots of space, but the decoder should be small, and it should maybe directed for 4Kintros...

I've see some examples with glsl, and i've count a lot of words like:
void,vec3,vec4,gl_,varying,attribute,1.0,2.0,0.0,.x,.y,.z,.xy

and so on... I believe that most of the 4k glsl already made, have some tecnics to strip the text code, spaces, small var names,...

it would be cool to make me tests with source codes of existent 4k and try play a little with this ideas. mybe someone can get a new intro tool ;)
having a tool which take expression like :

c = min(max(a,b),d); d=c*5;

and give this :

push a F1
push b F2
call max G0
push d F3
call min G1
push 5 E5
call mul G3

will be very cool but i'm not sure the size of the decompressor will be a benefit over the reduced size for a 1k.... maybe it can be a huge benefit for 4k/64k with very long shaders... or maybe generic compressor work as good as this...
added on the 2008-08-30 14:09:05 by Tigrou Tigrou
RufUsul/Tigrou: Don't even bother with RLE compression, as any well written LZ does do RLE implicitly: If You've eg. the sequence "00 00 00 00 00 00" you can code this as "<literal 00><match, offset -1, length 5>". So no reason to do anything RLEish explicitly.
added on the 2008-08-30 14:15:25 by kb_ kb_
I will save you the trouble, if it is about 1k you can scrap the idea altogether, it won't do any good.

Quote:

i check Metalwork source (which is d3d9 based) but seems even with pure asm + crinkgler dont let so much place for shaders...


Metalwork contains unnecessary data, colorstate is more accurate.

I have made a specific packer for 1k fx which perform better than the public version of crinkler, i just have to make a 1k for it and release the source, wait and see...

Quote:

Yeah, a hybrid LZ/RLE packer like Pucrunch for C64 should be pretty good for 1Ks (small decompressor, appropriate compression ratio).


Pucruncher or bitbuster or even exomizer won't be good enough.
added on the 2008-08-30 14:18:06 by hitchhikr hitchhikr
Tigrou: coding a 1k framework in asm isn't tough at all, you should go for it
added on the 2009-04-13 05:30:40 by ferris ferris
LZ is good value for the bytes you spend on the depacker, RLE isn't. (it's not much smaller than LZ and far less general). there's no reason to combine LZ+RLE on PCs, if you want RLE on top of a LZ, just allow match offsets of 1. huffman coding is pretty awful sizewise. an adaptive arithmetic coder is small and very good value.
added on the 2009-04-13 11:47:23 by ryg ryg
the best 4k compiler is where your heart is.
For 4k I prefer: the 0ok assembler (ask bero. bero do a frakking linux version of that frakking debugger because I loved to use that thing.) or NASM.
For 4k on windows - compression, just use crinkler.
For 1k on windows do dirty things and read the instructions from that other thread - somewhere on pouet.
For 1k on linux just rip the source from you massive clod or metatunnel.
added on the 2009-04-13 12:06:14 by las las
i won't read two pages of discussion because i'm drunk, but any assembler will do for 4k, and anything not an assembler won't do
added on the 2009-04-13 12:09:57 by blala blala
blala

your avatar said it all (=
added on the 2009-04-13 12:41:44 by RRROAR RRROAR
blala: this didn't use one single asm code (source code included). Post again when you're not drunk anymore :)
added on the 2009-04-13 12:48:09 by xTr1m xTr1m
best 4k compiler = use brainfuck, wonderful compression ratio.
added on the 2009-04-13 18:04:49 by Tigrou Tigrou
in linux: gcc -S + gnu as
added on the 2009-04-13 18:18:20 by pera pera

login