pouët.net

spooky re-wrote our intro into 100% asm

teh futare si won?

i use visual basic 4.

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'...

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.

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.

blueflame: heavily focused as in having one optional transform? :)

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 ???

I don't think it is possible to give it in binary form.

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...

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...



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? )

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

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...

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.

I will save you the trouble, if it is about 1k you can scrap the idea altogether, it won't do any good.



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...



Pucruncher or bitbuster or even exomizer won't be good enough.

Tigrou: coding a 1k framework in asm isn't tough at all, you should go for it

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.

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.

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

blala

your avatar said it all (=

blala: this didn't use one single asm code (source code included). Post again when you're not drunk anymore :)

best 4k compiler = use brainfuck, wonderful compression ratio.

in linux: gcc -S + gnu as