Sizetro framework for MSDOS (20 byte)
category: code [glöplog]
A "shadertoylike" boilerplate for MSDOS sizetros. Just combine X, Y and t in any way you like. For special cases this boilerplate can - of course - be way smaller ;)
In the raw form, it displays colored bars. If you change "your code" to, for example
it would give you a basic XOR Scroller =) I'm open to questions and suggestions.
Code:
mov al,0x13
nextframe:
inc di ; frame/time counter
nextpixel:
cwd
int 0x10 ; set mode/pixel
inc cx
jz nextframe
mov bx,320
mov ax,cx
div bx
; DX = x , AX = y , DI = frame/t
; weave them together into AL now =)
;;;;;;;;;;;;;;;;;;;
; ... your code ...
;;;;;;;;;;;;;;;;;;;
mov ah,0x0c
jmp short nextpixel
In the raw form, it displays colored bars. If you change "your code" to, for example
Code:
add dx,di
xor ax,dxit would give you a basic XOR Scroller =) I'm open to questions and suggestions.
nah, it's not stateless ;)
Depending a bit on what you want to do, wouldn't push 0a000h/pop es (or the les trick) combined with stosb be smaller? That wouldn't trash registers either, and not call a gazillion interrupts.
Doesn't seem to quit on ESC.
will this spawn lots of intros like puppyfarmer did?
@Preacher
If one creates X and Y from a running counter, the segment ES has to be pretty exactly 0xA000 so the LES trick unfortunately does not work everytime : you will get values like 0x9FFF or 0x9FC0 and the like. Decomposing the counter results than in an ugly offset, that is also why the version has 20 byte and not 19 (use LOOP instead of INC CX and JZ). So the PUSH version it would be (or the same sized alternative below). STOSB does not change any flags to notice us that the frame is over, so that has to be done by hand :/ All i could come up with is this one :
This is already 24 bytes long. There might be some tricks to shorten this one, but on the fly i don't see any. Of course, setting pixels with INT10 is WAY slower then adressing the memory - i once traced into the routine and dude, there is serious stuff going on in there ;) On the other hand, LUCY uses this approach and runs with reasonable speed, so i think that's okay ;)
@Gargaj
You're right. I thought about that several times and noticed that some people are very strict about ESCapeability, while others don't care, especially when the codesize is really low. I have a nice - probably spacesaving - idea to combine the ESC with a reasonable timer tool (a.k.a hardware independent animation speed) so let's see what i can do ;)
@movAX13h
I'm not sure i understand your comment, but i like your name =) He ... shouldn't that be movAL13h? ^^
If one creates X and Y from a running counter, the segment ES has to be pretty exactly 0xA000 so the LES trick unfortunately does not work everytime : you will get values like 0x9FFF or 0x9FC0 and the like. Decomposing the counter results than in an ugly offset, that is also why the version has 20 byte and not 19 (use LOOP instead of INC CX and JZ). So the PUSH version it would be (or the same sized alternative below). STOSB does not change any flags to notice us that the frame is over, so that has to be done by hand :/ All i could come up with is this one :
Code:
mov bh,0xa0
mov es,bx
mov al,0x13
int 0x10
nextframe:
inc si
nextpixel:
cwd
mov bx,320
mov ax,di
div bx
; DX = x, AX = y, SI = frame/t
; your code
stosb
test di,di
jz nextframe
jmp short nextpixel
This is already 24 bytes long. There might be some tricks to shorten this one, but on the fly i don't see any. Of course, setting pixels with INT10 is WAY slower then adressing the memory - i once traced into the routine and dude, there is serious stuff going on in there ;) On the other hand, LUCY uses this approach and runs with reasonable speed, so i think that's okay ;)
@Gargaj
You're right. I thought about that several times and noticed that some people are very strict about ESCapeability, while others don't care, especially when the codesize is really low. I have a nice - probably spacesaving - idea to combine the ESC with a reasonable timer tool (a.k.a hardware independent animation speed) so let's see what i can do ;)
@movAX13h
I'm not sure i understand your comment, but i like your name =) He ... shouldn't that be movAL13h? ^^
fragment shaders are stateless. in asm you can save vars from one frame to the next or write a var in one pixel and read it in the other. on shadertoy, that is not possible.
yes, my name comes from that line of code :) mov ax,13h is the same as mov al,13h if you dont care about ah or the number of instructions.
yes, my name comes from that line of code :) mov ax,13h is the same as mov al,13h if you dont care about ah or the number of instructions.
how about
?
I can't count bytes, sorry.
Code:
les bp,[bx]?
I can't count bytes, sorry.
@movAX13h
I see :) I'm curious about the impact of direct texture access in the near future though ;)
@g0blinish
Any version of
would do the oh-so-famous trick, just it never really gives you the 0xA000 you need for perfect horizontal alignment. Try yourself with showme.com. 3rd and 4th byte land in ES, in reverse order. If you know you're in DosBox you could just "INC ES" after, but you can't safely assume that ;)
Anyway, that would be 23bytes in size, and if we really don't care about perfect alignment because the animation does not rely on it, then we are at 22bytes (using LES straightforward). That's still two bytes to chop off to get to the size of the "slow" version, which itself can be even 19bytes small, if alignment is "not too" important.
I see :) I'm curious about the impact of direct texture access in the near future though ;)
@g0blinish
Any version of
Code:
les ??,[0]would do the oh-so-famous trick, just it never really gives you the 0xA000 you need for perfect horizontal alignment. Try yourself with showme.com. 3rd and 4th byte land in ES, in reverse order. If you know you're in DosBox you could just "INC ES" after, but you can't safely assume that ;)
Anyway, that would be 23bytes in size, and if we really don't care about perfect alignment because the animation does not rely on it, then we are at 22bytes (using LES straightforward). That's still two bytes to chop off to get to the size of the "slow" version, which itself can be even 19bytes small, if alignment is "not too" important.