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.
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.
TRY EVERY COMBINATION OF BYTES!
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.
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
will give you autoboot and more space directly. (though writing through to $0400 will load it onto the screen unless you move the pointers)
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)
x86 - please.
Code:
xor eax,eax
and
are your friends.
Code:
sbb eax,eaxare your friends.
what the fuck is this, x86 asm freshman year?
rtfm. intel's been supplying them since the beginning of time.
rtfm. intel's been supplying them since the beginning of time.
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?
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 (=
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?
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?
fizzer: yeah i have a little framework:
;)
Code:
void setup() { size(320,240); }
void draw() {
loadPixels();
// effect goes here;
updatePixels();
}
;)
Quote:
TRY EVERY COMBINATION OF BYTES!
:)
Gargaj: Ah, of course! =) ..and it's interesting how you ended that single-line comment with a semicolon, haha.
@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.
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.
to avoid any confusion: the script rather calls a compiler, than compiling on its own.
hmm, missed the point where its 512b. sue me
in general i think las isnt really interested in linux tinytros, here.
in general i think las isnt really interested in linux tinytros, here.
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.
trc_wm wins. FATALITY!
read the source of this
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)
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)
