pouët.net

Tiny Intro Toolbox Thread

category: code [glöplog]
It would like to ask some of our n byte intro (with n <=256b) experts to share their knowledge and tricks.
Where to start? What tools can you recommend for developing tiny intros on current systems?
And especially sharing some "standard tricks" (and some non standard tricks) would be pretty damn cool.
added on the 2012-05-14 15:19:39 by las las
TRY EVERY COMBINATION OF BYTES!
added on the 2012-05-14 15:30:41 by kusma kusma
I usually prototype in Processing, then when I'm done, I copy the code into Visual Studio and start turning it into ASM from the inside out (i.e. innerloops first) because it's easier to debug that way. Then when I'm done, I just copy that into NASM, convert the syntax, adjust the screen buffer / exit condition and essentially I'm done.
added on the 2012-05-14 15:42:13 by Gargaj Gargaj
Quote:
Where to start?

start reversing 4k/1k intros
Quote:
And especially sharing some "standard tricks" (and some non standard tricks) would be pretty damn coo

some from my draft article:
1.
mov al,13h
int 10h
ebx=0
2.
avoid temporary variables/ dos int 21h interrupts (allocate memory)

3.????

4. PROFIT!!1
if you're on c64 put your file at $007c , then you get 23 bytes of space with autoboot. (with a LOAD "*",8,1) You can increase that space but there are various bytes that have to be set (potentially wasted) further up in the memory.

Failing that
Code: *=$0326 .word start .byte $ed,$f6 start ; rest of code

will give you autoboot and more space directly. (though writing through to $0400 will load it onto the screen unless you move the pointers)
added on the 2012-05-14 19:00:20 by 4mat 4mat
x86 - please.
added on the 2012-05-14 20:13:40 by las las
Code:xor eax,eax
added on the 2012-05-14 20:23:30 by trc_wm trc_wm
and
Code: sbb eax,eax

are your friends.
added on the 2012-05-14 20:24:54 by trc_wm trc_wm
what the fuck is this, x86 asm freshman year?

rtfm. intel's been supplying them since the beginning of time.
added on the 2012-05-14 21:05:55 by superplek superplek
Gargaj: That sounds like a great way to work. I'm just getting into Processing myself, but I wasn't sure how useful it would be to convert a prototype over to another language. Do you always start from scratch in Processing, or do you have some handy extras of your own?
added on the 2012-05-14 21:21:56 by fizzer fizzer
I have no real tricks to offer :( But I hope some of the experts will share stuff here so I can sneak a peek :D

But to give an answer:
I guess all you need to start are 3 things: Init your mode (e.g. 13h), drop a pixel and exit by pressing ESC. At least it worked out for me that way (or 4 things if you add some framebuffer).

Little "trick": If you need some constant but you can't include one, just use a part of your compliled code (if your hex editor shows you an acceptable value). And if you change the value make sure the code runs just once before you change it :D

Nasm seems to be very very common. I use fasm. Why? Why not :D Well I guess that's it for now. Not much but I tried (=
And I guess you all use DOSBox or something like that?
added on the 2012-05-14 21:41:31 by las las
I'm glad to work under XP (DOSBox only for checking if the stuff runs there correct too).
I guess any form of binary compression w/ a stub, or "vm trickery" is a no-go for something as small as 256 bytes? Has anyone experimented with any?
added on the 2012-05-14 21:57:19 by r-A r-A
fizzer: yeah i have a little framework:
Code: void setup() { size(320,240); } void draw() { loadPixels(); // effect goes here; updatePixels(); }

;)
added on the 2012-05-14 23:21:38 by Gargaj Gargaj
Quote:
TRY EVERY COMBINATION OF BYTES!


:)
added on the 2012-05-14 23:33:17 by faraday faraday
Gargaj: Ah, of course! =) ..and it's interesting how you ended that single-line comment with a semicolon, haha.
added on the 2012-05-15 00:32:19 by fizzer fizzer
@r-A: this demo uses some tricks that i dont understand.
a c source is compressed and appended to a script, that will extract the source and compile it. though, the crazy part is, that the c source is created from an asm file. also, its for linux.
added on the 2012-05-15 02:35:59 by vectory vectory
to avoid any confusion: the script rather calls a compiler, than compiling on its own.
added on the 2012-05-15 02:37:24 by vectory vectory
hmm, missed the point where its 512b. sue me
in general i think las isnt really interested in linux tinytros, here.
added on the 2012-05-15 02:40:23 by vectory vectory
Quote:
And I guess you all use DOSBox or something like that?

DOSBox+debugger 0.73
Fasm Dos/Win
OllyDBG if stuck w/FPU
Quote:
what the fuck is this, x86 asm freshman year?

yes.
added on the 2012-05-15 10:47:34 by trc_wm trc_wm
trc_wm wins. FATALITY!
added on the 2012-05-15 14:10:32 by gloom gloom
read the source of this
added on the 2012-05-15 14:34:59 by quasimodo quasimodo
writing some prototypes and tests in Turbo C++ 3.0 (Borland) can also help :

it same environment / limitations as DOS (no surprises)
its C, so code can be easily changed (at least easier than asm)
final conversion to asm will be quite easy (C is very close to machine)
added on the 2012-05-15 14:45:53 by Tigrou Tigrou

login