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.
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!)
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 :
there is another possibility :
This is something pretty common in a lot of 2D/3D intros.
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.
Tigrou
Yes, pretty common construction:
Or if ah < 128 before L:, use cwd.
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.
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.
woa there!
really? any reason to not just use equ and $ to define labels after the fact? like this:
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
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 ;)
For the other things... Just a style question imho - and yeah - that $-2 thing looks way better ;)
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!)
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.
101, tiny for-next contest!11eleven)
what you say?
an optimizing assembler, really? :) dear lord...
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 =)
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 =)
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.
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.
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.
Puls uses this - it's about 6 bytes shorter:
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).
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).
great post rrrola
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/
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.
that's to accommodate with 16:9 and 16:10 screens :). That's crazy.
yes, but: normal 320*200 pixels have ratio 1.2:1, "new" pixels are 1.2/320*256=0.96:1
ratio on 4:3 screens
it was, in fact, a joke...