pouët.net

Tiny Intro Toolbox Thread

category: code [glöplog]
Quote:
And as long it runs with a non emulated DOS on a current machine - you have to deal with the fact that it is a totally valid demoscene related coding platform.


Alow me to underline the validty of this. What basically happened for these intros, bigger than let's say 32 bytes is this: speedwise it became feasible to do more intensive per-pixel FPU-based calculations. This was not really the case before.

And this very fact creates a new interesting challenge to offer pretty traced (or otherwise more complex) effects in small intros.

Native or semi-native DOS on a fast machine is a valid platform. Lets keep emulation out of the equation here and your 486 too (however much it hurts me to discredit my loyal DX2/66). Can't run? Youtube. I do that for odd platforms all the time.

Carry on, men.
added on the 2012-05-31 21:42:00 by superplek superplek
well. 16-bit-coding stays 16-bit-coding (i reread what ryg said) and so i came to the conclusion that DOS is valid as long as it just runs on any machine (except ones running with 64bit-OS!)
altho: whoever hijacked my pc earlier (again): (while i dont think it was a demoscener) that sucked! never do that again or i will stop computing! not for me that is, just for everyone! ;) EFF YA! imma spawn some saddam-disk-validator on your sys, jus slightly deformed, so it attacks your DDOS-Batch to DDOS yourself! FOREVER! :p the MailBombs sucked pretty hard aswell, but imma make a millions out of your thousands! :p
that SOOO sucked! PR!CK! just stop it right now, else i cant guarantee for internets health anymo! :p not only yours, but everyones, (AGAIN!)
does anybody have an idea for smallest asm code for something like this :
Code:for(y = 0; y < 200; y++) { dy = y - 100; for(x = 0; x < 320; x++) { dx = x - 160; //use dx, dy } }


there is another possibility :

Code:for (i = 0; i < 64000; i++) { x = (i % 320) - 160; y = (i / 320) - 100; //use dx, dy }

This is something pretty common in a lot of 2D/3D intros.

added on the 2012-06-01 19:49:19 by Tigrou Tigrou
Tigrou
Yes, pretty common construction:
Code: L: mov bp, 320 mov ax, di xor dx, dx div bp sub ax, 100 sub dx, 160 ... stosb loop L

Or if ah < 128 before L:, use cwd.
added on the 2012-06-01 20:07:36 by frag frag
Code: [PALETTE CODE REMOVED - ax = cx = 0 after it] _mainloop: _loop: db 0xbb ; mov bx, 320 _320i: dw 320 ; pusha needed due to some other things happening ;) cwd mov ax, di div bx ; dx = x & ax = y db 0x81, 0xea ; sub dx, 160 _160i: dw 160 db 0x2d ; sub ax, 100 _100i: dw 100 [HUGE CHUNK OF MAGIC REMOVED] ; popa see above stosb loop _loop ; inc dx - used as "timer" + used in fpu stuff only anyways - it's on the stack after the pusha above exactly where one needs it. in al, 0x60 dec al jnz short _mainloop

This is what I use - labels for the words added in order to support simple and straightforward constant reuse.
added on the 2012-06-01 20:18:25 by las las
woa there!

Code:_loop: db 0xbb ; mov bx, 320 _320i: dw 320 ; [..] db 0x81, 0xea ; sub dx, 160 _160i: dw 160 db 0x2d ; sub ax, 100 _100i: dw 100


really? any reason to not just use equ and $ to define labels after the fact? like this:

Code: mov bx, 320 _320i equ $-2 sub dx, 160 _160i equ $-2 sub ax, 100 _100i equ $-2
added on the 2012-06-02 02:43:41 by ryg ryg
For the "sub ax, 100" - nasm produces the "wrong" 3 byter - thus there's not the constant you would expect at $-2.
For the other things... Just a style question imho - and yeah - that $-2 thing looks way better ;)
added on the 2012-06-02 12:47:40 by las las
grr. turn nasm optimizations off! that's a new feature that wasn't in the nasm i grew to love! (haven't actually checked, but i'm positive it's because newer NASMs will automatically 'shorten' "sub ax, imm" into the "sub ax, byte imm" form iff -128<=imm<=127; NASM used to not do this kind of stuff which is what you want for small intros!)
added on the 2012-06-02 21:29:26 by ryg ryg
Yep exactly - opts are turned on by default (-Oz iirc is on by default - but that's actually the only place in the whole thing where nasm thinks it knows shit better... it doesn't) and iirc you can't even override that with sub ax, word 100 - it still wants to take the damn byte & sign variant - even if both are 3 bytes.
added on the 2012-06-02 21:34:18 by las las
101, tiny for-next contest!11eleven)
what you say?
added on the 2012-06-02 23:23:33 by las las
an optimizing assembler, really? :) dear lord...
added on the 2012-06-02 23:39:17 by superplek superplek
las
You can override it with tag 'strict',
but sub ax, imm16 is also a special case and 3 bytes long.
"sub dx, strict word 100" is 4.
If you absolutely must do it in 4 bytes with ax,
insert dd 81E86400h =)
added on the 2012-06-03 00:01:35 by frag frag
no, the "sub ax, imm16" (general <op> ax, <imm16>) form is fine (we don't need no stinkin' ModR/M!). the problem is just nasm deciding to narrow operands when it shouldn't.
added on the 2012-06-03 02:10:00 by ryg ryg
Quote:
an optimizing assembler, really? :) dear lord...

this level of optimization (well, this and picking sizes of jumps automatically) was something that all x86 assemblers except for nasm used to do, and (at least for me) one of the reasons i ended up switching to nasm.
added on the 2012-06-03 02:42:02 by ryg ryg
okay that strict thing works. thanks. But imho nasm should do that anyways. especially with sub ax, word 100 & both variants are the same size.
added on the 2012-06-03 02:51:31 by las las
Puls uses this - it's about 6 bytes shorter:
Code: for (uint16 i = 0; i < 65536; i++) // automatic wrap { int16 dx = (i * 0xCCCD - Center) >> 8; // automatic modulo to ±32767 int16 dy = (i * 0xCCCD - Center) >> 16; // ±20480 //use dx, dy }

Center is a constant that maps (159.5, 99.5) to (0,0), can be killed using segment magic.
The >>8 and >>16 are also free (pusha + byte addressing into the stack).
added on the 2012-06-03 11:08:18 by rrrola rrrola
great post rrrola
added on the 2012-06-03 12:12:53 by Tigrou Tigrou
Quote:
this level of optimization (well, this and picking sizes of jumps automatically) was something that all x86 assemblers except for nasm used to do, and (at least for me) one of the reasons i ended up switching to nasm.
#


wasn't really aware in the tasm era, afterwards switched to nasm too.

rrrola \o/
added on the 2012-06-03 17:15:03 by superplek superplek
bump
rrrola: nice method! But your approach changes the aspect ratio slightly - right? Might not be that much of a problem depending on what you want.
added on the 2012-06-04 18:00:12 by las las
that's to accommodate with 16:9 and 16:10 screens :). That's crazy.
added on the 2012-06-04 20:02:07 by Tigrou Tigrou
yes, but: normal 320*200 pixels have ratio 1.2:1, "new" pixels are 1.2/320*256=0.96:1
added on the 2012-06-04 23:29:43 by rrrola rrrola
ratio on 4:3 screens
added on the 2012-06-04 23:30:11 by rrrola rrrola
it was, in fact, a joke...
added on the 2012-06-04 23:49:53 by Tigrou Tigrou

login